When is a duck not a duck?
Posted: Thu Feb 09, 2012 2:34 pm
Method A
Notice method 'A' above how the official code sample taken straight out of the PureBasic Help file illustrates a nice clean direct method of detecting the Return key being pressed.
Notice method 'B' below how the code sample illustrates a cyclic event taking place between two 'focus' related events and shortcut assignments, toggling a feature in the system on and off? -- effectively accomplishing the same behavior as intended in method 'A' seen above?
Method B
This is not a debate about what was, what could be or what fell off the plate without so much as even the slightest mention of any changes in the PureBasic history notes. Nor is it a debate on the quality of the PureBasic language, the user group or programming preferences.
Method 'A' is evidently not an available option, so if you want to use it then that alone presents a problem. A problem that may be addressed by other means, but a problem nonetheless.
Method 'B' generates a menu event to toggle a feature in the system on and generates a menu event to toggle the feature off again.
There is only one question here. Does method 'B' provide a means to overcome the absence of functionality as intended in method 'A'?
Now, before you answer, take a look at what we have here.
Dictionary definition
Does method 'B' provide a means to overcome the absence-of-functionality (a problem) as intended in the program code illustrated in method 'A'?
Private Message is available if you don't want to answer publicly. Either way I would appreciate the feedback. Really don't like being told I am full of shit because I am willing to accept that a duck is a duck, a rose is a rose and a workaround is a workaround where others are not so willing.
Code: Select all
Repeat
EventID = WaitWindowEvent()
If EventID = #PB_Event_Gadget
Select EventGadget()
Case 0
If EventType() = #PB_EventType_ReturnKey
MessageRequester("Info", "Return key pressed", 0)
SetActiveGadget(0)
EndIfNotice method 'B' below how the code sample illustrates a cyclic event taking place between two 'focus' related events and shortcut assignments, toggling a feature in the system on and off? -- effectively accomplishing the same behavior as intended in method 'A' seen above?
Method B
Code: Select all
Repeat
EventID = WaitWindowEvent()
liveWin = GetActiveWindow()
Select EventID
Case #PB_Event_Gadget ;only one gadget list for all windows
EventTyp.l = EventType()
Select EventGadget()
Case 0, 2
Select EventType()
Case #PB_EventType_Focus
Debug "focus on window " + Str(liveWin)
If IsWindow(liveWin)
AddKeyboardShortcut(liveWin, #PB_Shortcut_Return, #KB_Return)
EndIf
lastLiveWin = liveWin
Case #PB_EventType_LostFocus
Debug "lost focus on window " + Str(lastLiveWin)
If IsWindow(lastLiveWin)
RemoveKeyboardShortcut(lastLiveWin, #PB_Shortcut_Return)
EndIf
EndSelectMethod 'A' is evidently not an available option, so if you want to use it then that alone presents a problem. A problem that may be addressed by other means, but a problem nonetheless.
Method 'B' generates a menu event to toggle a feature in the system on and generates a menu event to toggle the feature off again.
There is only one question here. Does method 'B' provide a means to overcome the absence of functionality as intended in method 'A'?
Now, before you answer, take a look at what we have here.
Dictionary definition
- workaround — n
a method of circumventing or overcoming a problem in a computer program or system
Does method 'B' provide a means to overcome the absence-of-functionality (a problem) as intended in the program code illustrated in method 'A'?
Private Message is available if you don't want to answer publicly. Either way I would appreciate the feedback. Really don't like being told I am full of shit because I am willing to accept that a duck is a duck, a rose is a rose and a workaround is a workaround where others are not so willing.
