Cross Platform -- Detect StringGadget Carriage Return Key

[Randy Walker]

So, all that code was just satirical? Because I thought you were insane.

''Technology breeds insanity''

[remi_meier]

For real use I think you should still go with a AddKeyboardShortcut().
Frankly, I don't see a problem with this code:
...
It's a bit of a workaround but it seems to work fine. Managing
the events (MenuItemIDs, etc.) might be a bit tedious but at
least it seems to work

Because like all workarounds attempting to manage this void, it has its own shortcoming. In this case, your solution broke the [Return] key. Here is your code modified to include an editor gadget that should by rights be able to carriage return and line feed to the next line when you press enter, but it doesn't, becasue AddKeyboardShortcut broke it: [..]

Alright, didn't think about that

Actually, in other GUI toolkits I know this problem is simple
to solve because they expose the widget-hierarchy to the
client and therefore there is a chain of event-handlers which
each can say "I don't know what to do with this keypress"
or "I'll handle it!". It's hard for me to come up with a clean
solution to that problem in PB.
Maybe we should just be able to add KeyboardShortcuts()
to individual gadgets, too.

Oh well, I gotta go

[netmaestro]

Handle the focus events and nothing gets broken:

Code: Select all

OpenWindow(0,0,0,640,480,"",#PB_Window_ScreenCentered|#PB_Window_SystemMenu)

TextGadget(#PB_Any, 10,20,100,16,"Enter Something:")
StringGadget(0, 110,20,300,20,"")
EditorGadget(1,10,50,400,400)
SetActiveGadget(0)

Repeat
  EventID = WaitWindowEvent()  
  Select EventID
    Case #PB_Event_Gadget
      Select EventGadget()
        Case 0
          Select EventType()
            Case #PB_EventType_Focus
              AddKeyboardShortcut(0, #PB_Shortcut_Return, 10)
            Case #PB_EventType_LostFocus
              RemoveKeyboardShortcut(0, #PB_Shortcut_Return)
          EndSelect
      EndSelect
    Case #PB_Event_Menu
      Select EventMenu()
        Case 10
          SetActiveGadget(1)
      EndSelect
  EndSelect
Until EventID = #PB_Event_CloseWindow

[IdeasVacuum]

....looks like a very good solution netmaestro.

[Randy Walker]

Handle the focus events and nothing gets broken:

Ummm ... I think look again and see its broken if only you try to expand on it to make it more than exclusive demo window with 2 only edit boxes. What is that ''Select EventMenu() : Case 10" thingy doing in there? The reason I ask is its messing with my Popup when I select ''TextE.txt'' << item #10 in my picklist.

Code: Select all

OpenWindow(0,0,0,640,480,"",#PB_Window_ScreenCentered|#PB_Window_SystemMenu)

TextGadget(#PB_Any, 10,20,100,16,"Enter Something:")
StringGadget(0, 110,20,300,20,"")
EditorGadget(1,10,50,400,400)
SetActiveGadget(0)

If CreatePopupMenu(0)      ; creation of the pop-up menu begins...
  MenuItem(1, "Open")      ; You can use all commands for creating a menu
  MenuItem(2, "Save")      ; just like in a normal menu...
  MenuItem(3, "Save as")
  MenuItem(4, "Quit")
  MenuBar()
  OpenSubMenu("Recent files")
    MenuItem(5, "PureBasic.exe")
    MenuItem(6, "TestA.txt")
    MenuItem(7, "TestB.txt")
    MenuItem(8, "TestC.txt")
    MenuItem(9, "TestD.txt")
    MenuItem(10, "TestE.txt") ; << Limit Popup to less than 10 items.  Why that???
  CloseSubMenu()
EndIf

Repeat
  EventID = WaitWindowEvent() 
  Select EventID
    Case #WM_RBUTTONDOWN       ; right mouse button was clicked =>
      DisplayPopupMenu(0, WindowID(0))  ; now display the popup-menu
    Case #PB_Event_Gadget
      Select EventGadget()
        Case 0
          Select EventType()
            Case #PB_EventType_Focus
              Debug "focus"
              AddKeyboardShortcut(0, #PB_Shortcut_Return, 10)
            Case #PB_EventType_LostFocus
              Debug "lost"
              RemoveKeyboardShortcut(0, #PB_Shortcut_Return)
          EndSelect
      EndSelect
    Case #PB_Event_Menu
      Select EventMenu()
        Case 10
          SetActiveGadget(1)
          ; So this is not broken if I add in more workaround... right?
      EndSelect
      Select EventGadget()
        Case 1 : Debug "Menu: Open"
        Case 2 : Debug "Menu: Save"
        Case 3 : Debug "Menu: Save as"
        Case 4 : Debug "Menu: Quit"
          EventID = #PB_Event_CloseWindow
        Case 5 : Debug "Menu: PureBasic.exe"
        Case 6 : Debug "Menu: TextA.txt"
        Case 7 : Debug "Menu: TextB.txt"
        Case 8 : Debug "Menu: TextC.txt"
        Case 9 : Debug "Menu: TextD.txt"
        Case 10 : Debug "Menu: TextE.txt"
          ; I didn't ask EventMenu case 10 to mess with this filter??
      EndSelect
  EndSelect
Until EventID = #PB_Event_CloseWindow 

''A rose is a rose is a rose'', same as it is with a workaround ... is a workaround is a workaround. Right?

[netmaestro]

So start your keyboard shortcut menu#'s at 50. Or 100. Just adjust them to avoid collisions. It's not a workaround, this is what the focus events on string gadgets are for. You can add ESC or any key combos you want, just add the list of them on focus and remove them on lostfocus. Also, you can use say 100-105 for one string gadget, 106-110 for another, etc. so your event loop always knows what string gadget generated the keypress.

[Randy Walker]

....looks like a very good solution netmaestro.

netmaestro is good. He is very good! Helped me many times in the past and I know able to write code miles over my head. I think this time we are simply looking at a void in the language that people have simply grown accustomed to managing though workarounds. Do it long enough, it seems normal and acceptable, but its still a workaround. As someone pointed out earlier, these AddKeyboardShortcut solutions *borrow* from facilities designed in the OS to manage *menus* -- not keys. Thats why this strategy is a workaround and will never be a proper solution.

[Randy Walker]

As someone pointed out earlier, these AddKeyboardShortcut solutions *borrow* from facilities designed in the OS to manage *menus* -- not keys. Thats why this strategy is a workaround and will never be a proper solution.

Is it legal to quote myself in this forum???

[luis]

Yup, I used the same mechanism on a program using subclassing because I had other things to do too, but as netmaestro shown we can use #PB_EventType_Focus instead.

Used enum to avoid event numbering collision and worked fine.

Code: Select all

       
        ; combo control get focus
        If HIDWORD (wParam) = #CBN_SETFOCUS
            AddKeyboardShortcut(#WIN_MAIN, #PB_Shortcut_Return, #EVT_COMBO_RETURN)            
        EndIf

        ; combo control lose focus
        If HIDWORD (wParam) = #CBN_KILLFOCUS            
            RemoveKeyboardShortcut(#WIN_MAIN, #PB_Shortcut_Return)
        EndIf

EDIT: I admit it's not beautiful and a little time consuming.... it's the best way I found at the time.

Yes, it's a little convoluted.

[Randy Walker]

So start your keyboard shortcut menu#'s at 50. Or 100. Just adjust them to avoid collisions. It's not a workaround,...

I think this time we are simply looking at a void in the language that people have simply grown accustomed to managing though workarounds. Do it long enough, it seems normal and acceptable, but its still a workaround.

But if we want to rationalize to make justification for sticking to a workaround then we can add to our argument...

... this is what the focus events on string gadgets are for.

But, no... it truly is a workaround and so I feel justified in quoting myself again...

...these AddKeyboardShortcut solutions *borrow* from facilities designed in the OS to manage *menus* -- not keys. Thats why this strategy is a workaround and will never be a proper solution.

[netmaestro]

It's crossplatform, it works, not just for the return key but for any key or combination, I'm happy with it. Some will consider it to be a workaround to be sure, and I don't mind that. Is it a workaround? To quote a very famous very slippery fellow, I suppose that depends on what your definition of "is" is.

[Randy Walker]

Lets see if we can put this comment into proper light so we can all see that it definitley and quite *literally* is a workaround.

So start your keyboard shortcut menu#'s at 50. Or 100.

Here you indirectly acknowledge the '10' menu code gets in the way, as in, it is an *obsticle* that you must *workaround* to avoid collision with genuine menu items. And (in other words) if you do not *workaround* then you will encounter collision. << NOT something that would be possible with a nice clean proper solution designed to accommodate keyboard management.... right?

Plain and simple -- it is a workaround.

Not trying to aggrevate you netmaestro. I really do value you feedback and for what it is worth, I will be doing what I can to adapt this workaround to my code in hopes that I can regain control of my program. At least, until a proper solution comes along. Meanwhile, I'm not going to try to convince myself it is a proper solution to keyboard management. I do use a numper of popups and it is quite clear to me, I will have to design some workaround values into my code to avoid these new AddKeyboardShortcut obsticles.

[netmaestro]

No worries, I'm not the least bit aggravated. Hardly anybody ever agrees with me!

[Tenaja]

Lets see if we can put this comment into proper light so we can all see that it definitley and quite *literally* is a workaround.

So start your keyboard shortcut menu#'s at 50. Or 100.

yada yada yada...

I'm with Randy...the biggest "issue" with the workaround is that how can a newbie "know" what values are "safe?" Fred has defined PB as "for beginners," so how would a beginner know how to do this?

It really would be nice to have a more robust solution.

[IdeasVacuum]

Heck, there isn't even one place to find a list of all of the pre-defined codes

Do you mean the constants? http://www.purebasic.com/documentation/ ... tants.html

What Fred actually says is

PureBasic has been created for the beginner and expert alike.

Which by definition means that for some aspects of the language, beginners will probably need a helping hand from experts - which is what netmaestro delivers on an almost daily basis.