Re: Cross Platform -- Detect StringGadget Carriage Return Ke
Posted: Mon Feb 06, 2012 2:34 pm
''Technology breeds insanity''MachineCode wrote:So, all that code was just satirical? Because I thought you were insane.
http://www.purebasic.com
https://www.purebasic.fr/english/
''Technology breeds insanity''MachineCode wrote:So, all that code was just satirical? Because I thought you were insane.
Alright, didn't think about thatRandy Walker wrote:remi_meier wrote: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 workBecause 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: [..]
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
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.netmaestro wrote: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)
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
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.IdeasVacuum wrote:....looks like a very good solution netmaestro.
Is it legal to quote myself in this forum???Randy Walker wrote: 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.
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
netmaestro wrote:So start your keyboard shortcut menu#'s at 50. Or 100. Just adjust them to avoid collisions. It's not a workaround,...
But if we want to rationalize to make justification for sticking to a workaround then we can add to our argument...Randy Walker wrote: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, no... it truly is a workaround and so I feel justified in quoting myself again...netmaestro wrote:... this is what the focus events on string gadgets are for.
Randy Walker wrote:...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.
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?netmaestro wrote:So start your keyboard shortcut menu#'s at 50. Or 100.
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?Randy Walker wrote: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.yada yada yada...netmaestro wrote:So start your keyboard shortcut menu#'s at 50. Or 100.
Do you mean the constants? http://www.purebasic.com/documentation/ ... tants.htmlHeck, there isn't even one place to find a list of all of the pre-defined codes
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.PureBasic has been created for the beginner and expert alike.