I have just looked through the documentation for a way to set the initial focused control but have not found one. I could create a focus event that said if the dlg gets focus then focus the one I want but I am wondering if there is another way like for example a :default-focus for the dlg? I add a listbox to the dialog then an edit box and then 3 buttons. It seems no matter if I add the edit box first or last or in the middle some where The dialog when shown always seems to focus the list box which I don't understand why that is.
Any ideas are greatly appreciated.
Ken
On 9/7/07, Ken Perry whistler@blinksoft.com wrote:
I have just looked through the documentation for a way to set the initial focused control but have not found one. I could create a focus event that said if the dlg gets focus then focus the one I want but I am wondering if there is another way like for example a :default-focus for the dlg? I add a listbox to the dialog then an edit box and then 3 buttons. It seems no matter if I add the edit box first or last or in the middle some where The dialog when shown always seems to focus the list box which I don't understand why that is.
Hi Ken. Try calling gfw:give-focus on the desired control in your initialization of the dialog.
One thing that I haven't decided whether I'm happy about is the behavior that occurs when any control has the focus and one switches to another window and then back. I find that I have to manually set the focus back, when one might expect that when the window is made active again, that the control that previously had focus would remember that state. I need to do some research and see if this is just normal Win32 behavior, and if it is, then I might think about providing some mechanism to handle this automatically. Your input is welcome.
I didn't even realize it didn't keep the correct focus when the application loses focus till you just wrote this. I can tell you this is not how Win32 normally works. If you would like I can send you both an EXE and an ASM win32 program that does the same thing as my lisp program which I am writing in your graphic-forms library. That way you could test how a pure win32 application works against your library if you like. If you want I can send my newest lisp file, my ASM file, and the EXE of the ASM file. If you don't trust that I am sending you just the simple program and I might not in your place I can also zip up the GOASM compiler and linker in the directory so you can make the ASM file for safety sake. I have a simple bat file that makes it so you don't have to fight learning to use the asm compiler and linker if you haven't used GoAsm before.
As for fixing it you could make a global *current-control-focused* or something like it so that when it returns and the activated event is called you can reset the focus.
Well let me know if you would like to see the comparison and I will zip it all up.
Ken -----Original Message----- From: graphic-forms-devel-bounces@common-lisp.net [mailto:graphic-forms-devel-bounces@common-lisp.net] On Behalf Of Jack Unrue Sent: Friday, September 07, 2007 9:56 PM To: graphic-forms-devel@common-lisp.net Subject: Re: [graphic-forms-devel] Dialog focus
On 9/7/07, Ken Perry whistler@blinksoft.com wrote:
I have just looked through the documentation for a way to set the initial focused control but have not found one. I could create a focus event that said if the dlg gets focus then focus the one I want but I am wondering if there is another way like for example a :default-focus for the dlg? I add a listbox to the dialog then an edit box and then 3 buttons. It seems no matter if I add the edit box first or last or in the middle some where The dialog when shown always seems to focus the list box which I don't understand why that is.
Hi Ken. Try calling gfw:give-focus on the desired control in your initialization of the dialog.
One thing that I haven't decided whether I'm happy about is the behavior that occurs when any control has the focus and one switches to another window and then back. I find that I have to manually set the focus back, when one might expect that when the window is made active again, that the control that previously had focus would remember that state. I need to do some research and see if this is just normal Win32 behavior, and if it is, then I might think about providing some mechanism to handle this automatically. Your input is welcome.
-- Jack Unrue _______________________________________________ graphic-forms-devel mailing list graphic-forms-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/graphic-forms-devel
On 9/7/07, Ken Perry kperry@blinksoft.com wrote:
I didn't even realize it didn't keep the correct focus when the application loses focus till you just wrote this. I can tell you this is not how Win32 normally works. If you would like I can send you both an EXE and an ASM win32 program that does the same thing as my lisp program which I am writing in your graphic-forms library. That way you could test how a pure win32 application works against your library if you like. If you want I can send my newest lisp file, my ASM file, and the EXE of the ASM file. If you don't trust that I am sending you just the simple program and I might not in your place I can also zip up the GOASM compiler and linker in the directory so you can make the ASM file for safety sake. I have a simple bat file that makes it so you don't have to fight learning to use the asm compiler and linker if you haven't used GoAsm before.
Well, I can certainly whip up a C-based Win32 app and explore this further, I just haven't done that yet.
As for fixing it you could make a global *current-control-focused* or something like it so that when it returns and the activated event is called you can reset the focus.
I suspect the fix involves some additional window style or event handling behavior that is missing. I'll do some research, as mentioned above.
Manually tracking focused controls (remember, an application may have multiple windows), whether that's done by the application or by Graphic-Forms, strikes me as the wrong solution.
Well let me know if you would like to see the comparison and I will zip it all up.
I don't think that will be necessary, but if I change my mind, I'll let you know. Thanks!
You said, "Well, I can certainly whip up a C-based Win32 app and explore this further, I just haven't done that yet."
Nod well I have this program in c, c++ and well just about every language its one reason we do it in all these languages so we can see how each work differently for the same task. So the offer still stands if you just want a version of the same program sample.
you said, "I suspect the fix involves some additional window style or event handling behavior that is missing. I'll do some research, as mentioned above."
I don't know what other event handling you would need to do. What I t looks like is your flow panels are taking the focus the default action of Win32 is to keep the location when you go back. I didn't have to do anything at all but write the add and delete functions and the focus stayed where it was supposed to. So I am thinking it has to be some code you have in the activated event base graphic-forms lisp code.
You said, "Manually tracking focused controls (remember, an application may have multiple windows), whether that's done by the application or by Graphic-Forms, strikes me as the wrong solution."
Your right of course I totally was not thinking when I sent that answer. I am going to have a look through your code just to get a feel for how it works. Up till now I was only looking in your API documentation to get my small dialog based app working. One thing I found missing in your docs are examples. Your chm is fine for old time coders but for beginners in the language it doesn't give an example call for functions which would be helpful.
Ken
graphic-forms-devel@common-lisp.net
-
Jack Unrue -
Ken Perry -
Ken Perry