When is a duck not a duck?

[Randy Walker]

Method A

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)
        EndIf

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

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
          EndSelect

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

• workaround — n
  a method of circumventing or overcoming a problem in a computer program or system

Simple question:
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.

[Trond]

Does method 'B' provide a means to overcome the absence-of-functionality (a problem) as intended in the program code illustrated in method 'A'?

I have no idea why you want to overcome an intended absence of functionality.

Further, you don't say what kind of functionality you (don't?) intend to have, so answering the question is quite impossible.

Maybe if you describe the high-level behaviour you want your gui to have, someone can show you the best way to do it, within present limits.

Edit: After re-reading your definition of workaround, it seems to me like computer programming is, by its nature, a workaround. A program is always written to overcome some problem, else we wouldn't need it.

[IdeasVacuum]

Edit: After re-reading your definition of workaround, it seems to me like computer programming is, by its nature, a workaround. A program is always written to overcome some problem, else we wouldn't need it.

In this case, the term 'work-around' is not referring to the problem that the application is designed to solve, but to a method of getting code to perform an action or calculation even though there is some kind of obstacle - perhaps a lack of programming language functionality or a language function that has a bug, or something OS specific etc. So, the 'work-around' would be a means of avoiding the obstacle and producing a satisfactory application.

This post is essentially the same as http://www.purebasic.fr/english/viewtop ... 4&start=45 and http://www.purebasic.fr/english/viewtop ... 13&t=49100

The debate essentially boils down to whether PB's functionality in a certain case, which works, could be simplified or easier to deploy. As with everything in life, some will say yes and others will say no. As with everything in life, when you examine a situation, it's never as straight forward, black-or-white, yes-or-no as it first appeared. So, whilst everyone can agree that a duck is a duck, we may differ in preference of duck type. Nothing wrong with having a different preference, so that should be the end of the debate should it not?

[Demivec]

Dictionary definition
workaround — n
a method of circumventing or overcoming a problem in a computer program or system

Putting first things first, and for the sake of completeness, the definition you posted should be extended by a few more words to read:

workaround — n
a method of circumventing or overcoming a problem in a computer program or system, without eliminating it

Simple question:
Does method 'B' provide a means to overcome the absence-of-functionality (a problem) as intended in the program code illustrated in method 'A'?

I agree with Trond with respect to the question, namely, that it can't be answered without knowing what is being overcome.

Notwithstanding that lack of information, both methods use events to detect a return key being pressed if a given gadget has the focus. The commands provided are intended to be used for event processing, thus no workarounds in that respect.

I also agree with IdeasVacuum who describes all programming solutions as 'workarounds' because they deal with overcoming problems (i.e. printing a report) without eliminating it. To me that means that if a workaround is seen as too burdensome then a feature request is probably in order to eliminate the perceived problem.

[skywalk]

LOL...every Procedure and Macro I've written is a workaround.

[Randy Walker]

Does method 'B' provide a means to overcome the absence-of-functionality (a problem) as intended in the program code illustrated in method 'A'?

I have no idea why you want to overcome an intended absence of functionality.

Further, you don't say what kind of functionality you (don't?) intend to have, so answering the question is quite impossible.

Really?
Et tu Trond? Et tu?

Ok. well I don't really know how I can make it any clearer without being insulting which I've been trying really hard not to do, so please pardon me for giving credit. If we read the code in the original post it quite clearly shows only one line of code that we all know you do not use every day.

Code: Select all

If EventType() = #PB_EventType_ReturnKey

I think you can find it... and FOR ME that line in PureBasic v3.30, v4.20 and v4.60 does not trap any condition whatsoever (and I think it safe to say) "as originally intended". Again, there seems to be a common trend to avoid answering a very simple and direct question that has only 2 possible answers. Could make a person wonder what that reason is. I could guess ill, but here. Let me try this for size as an easy explaination that might appease everyone:

Easy enough every one here to say “we don’t want Fred and his team wasting time on this when we have interests of greater concern and so we are not going to support your quest for a direct solution, but we would be happy to share the workaround we use and help you find a way to make it suitable to your needs. Ultimately that was the result of the full encounter on the topic over in 'Coding Questions'. I think better to be honest, skip the nonsense and get to the final resolution than trying to convence me a duck is not a duck.

[c4s]

I believe that 1 year ago there was a pretty similar discussion on the German forum. I think the conclusion was that the changed behavior of #PB_Event_Focus is a bug fix, freak's comment about it: http://www.purebasic.fr/german/viewtopi ... 83#p284683 (Google translation)

[freak]

Could you please keep this discussion in one place and not open new threads around the forum?

[Trond]

Randy Walker, you already know the answer to your question, so why do you bother asking it? The opinions of others need not matter to you.

Code: Select all

If EventType() = #PB_EventType_ReturnKey

I think you can find it... and FOR ME that line in PureBasic v3.30, v4.20 and v4.60 does not trap any condition whatsoever (and I think it safe to say) "as originally intended".

Different gadgets support different eventtypes. This particular event type does not seem to be supported by any gadget. Because it is not supported by any gadget I cannot know for which gadget it is defunct and for which gadget you need a solution. When I'm talking about behavior, I mean that reacting to return on a gadget that takes keyboard focus (string gadget) is very different to reacting to return on a gadget that does not (image gadget). You didn't tell, so I don't know.

Further, code B does not trap the return key. And you claim code B does what you wanted. So obviously you don't want to trap the return key, because code B doesn't do that. Rather it adds and removes the return key shortcut as the window loses and gains focus. I have no idea why you do this. If the window doesn't have focus a keyboard shortcut cannot be triggered. There is no need to remove it and add it all the time. (Unless you have big bugs in your event handling or there is some other bug I'm not aware of.)

I do not at all agree that a duck is a duck. "Duck" could also, for instance, refer to a rubber duck, which, technically, is not a duck.

In this case, with the word workaround, there are also different types of workarounds. The word workaround is most often used to mean "work around a bug". But sometimes it can mean "work around an inherent limitation" or "work around a missing feature".

It is my opinion that in this case, if you want to trap the enter key, the code that does so can be called a workaround (a missing feature), because it does not "flow naturally" they way it would, if the feature was there.

It is my opinion that in this case, code B is not a workaround, because it does not trap the enter key, which is what I assume you want.

It is also my opinion that working around a missing feature is much less severe than having to work around a bug. Thus it can give the wrong impression regarding how serious this is when you use the word "workaround". Which is probably why not everyone wants to call this a "workaround".

Here is a code that is a workaround for the missing feature of trapping the return key. I hope that is what you want:

Code: Select all

#Menu_Return = 1


W = 110
H = 384
OpenWindow(0, 0, 0, W, H, "", #PB_Window_ScreenCentered | #PB_Window_MaximizeGadget | #PB_Window_MinimizeGadget | #PB_Window_SizeGadget)
StringGadget(0, 10, 10, 100, 22, "")
StringGadget(1, 10, 40, 100, 22, "")
StringGadget(2, 10, 70, 100, 22, "")

AddKeyboardShortcut(0, #PB_Shortcut_Return, #Menu_Return)

Repeat
  Event = WaitWindowEvent()
  Select Event
    Case #PB_Event_Menu
      Select EventMenu()
        Case #Menu_Return
          Active = GetActiveGadget()
          Select Active
            Case 0, 1
              Debug "Return in " + Str(Active) + ": " + GetGadgetText(Active)
              SetGadgetText(Active, "")
            Case 2
              If Not (Val(GetGadgetText(Active)) Or GetGadgetText(Active) = "0")
                Debug "Please enter a numeric input!"
              Else
                Debug GetGadgetText(Active)
                SetGadgetText(Active, "")
              EndIf
          EndSelect
      EndSelect
    Case #PB_Event_CloseWindow
      CloseWindow(0)
      Break
  EndSelect
ForEver

[IdeasVacuum]

Randy, you are beginning to sound like a troll. A number of experienced, wise developers have given their opinion on this subject and offered code to help you. It does not matter if you agree or disagree with your peers on this forum, but you really are digging a hole for yourself by continuously raising the same issue in different posts and trying to, what? Climb the hill so that you can sing "I'm the King of the Castle"?

If you are unhappy about a feature of PB, that's OK - put in an enhancement request and work with what you have got for now. If that isn't good enough for the application you are working on, code it in another language that is more suited.

[Randy Walker]

Could you please keep this discussion in one place and not open new threads around the forum?

The reason for the multiple posts, at first I was acting in a manner of respect from a previous incident here in the forums. I was ''set in my place'' (so to speak) by one of the other members for mistakenly posting what I thought was a bug and turned out to be a programming error on my part. I was told I should have posted in the 'Coding Questions' first and let the senior users determine whether or not it was worthy of being reported as a bug. Ok, sounds reasonable, right?

Almost, everyone chose to ignore the closing comment in my original post on this topic where I specifically asked if anyone could provide a direct solution that was not a workaround. That question was specifically ignored, but now the net result of all this bantering correlates back to my original intent -- Get the issue into the public eye where I know the "experts" have seen it and then let it rest entirely on their shoulders as to whether or not *they* want to delare it a bug or not. Out of my hands now and up to the professionals where it all leads from here. This is my last post on the topic.

Sincere thanks to you Freak for your time. Sorry about all the commotion. Please extend my appologies and gratitude to Fred and the rest of the team when you see them.

Even though not what I asked for, thanks again to all that took time to offer up their suggestions... .. click (poof)

[yrreti]

To Trond
I can remember doing a workaround a long time ago for that problem in the past, but
that's a nice little piece of code you posted. It's simple and works well.
Thanks for sharing it.