From: Diederick C. N. <dc...@gm...> - 2012-06-19 03:49:29
|
Dear Manfred, I'm sorry you're having problems reaching the mailing list. did you register for it? I'm not sure what could be causing this problem. We have a demo that comes with freeglut that does menus (one is its name) and this works fine on my windows machine. One difference I see between that demo and your code is that the menus are created before the window is opened, but that really shouldn't matter. Could you track down the one demo in your distribution of freeglut 2.8 and try if that works? Are you using Fedora yourself as well? Best, Dee On Tue, Jun 19, 2012 at 1:24 AM, Manfred Spraul <ma...@co...>wrote: > Hi, > > I know that it is impolite to send personal mails, but it seems that I > can't post to the freeglut-developer list :-( > > Do you have any idea what could be causing the problem described below? > Feel free to forward the mail to the mailing list. > > -- > Manfred > > > -------- Original Message -------- Subject: incompatibility between > freeglut-2.6 and freeglut-2.8 with menus Date: Sun, 17 Jun 2012 14:12:33 > +0200 From: Manfred Spraul <ma...@co...><ma...@co...> To: > fre...@li... > > Hi, > > I've observed that the (popup) menu from cgx stopped working after > upgrading from freeglut-2.6 to freeglut-2.8. > The code works with glut-3.5, freeglut-2.4, freeglut-2.6. > With freeglut-2.8 it stopped working. > I've tested with freeglut-2.8.0 from Fedora FC17. > As far as I can see, it's based onfreeglut-2.8.0.tar.gz from Jan 2012 > without any changes. > (1 patch that affects the -L flags for the demos) > > Are there any known bugs? > Are any special initializations required? > > Attached is a test case: freeglut-2.6 shows a menu, freeglut-2.8 doesn't. > The full cgx source code is available from http://calculix-rpm.sourceforge.net/ > > -- > Manfred > > > > > > |
From: <ipe...@it...> - 2012-06-19 13:57:01
|
I have the same problem with Manfred in Windows XP. Experimenting, I have noticed that menus don't appear if an entry callback is defined with glutEntryFunc. If we don't define this one, the menus appear normally. Ioannis Quoting "Diederick C. Niehorster" <dc...@gm...>: > Dear Manfred, > > I'm sorry you're having problems reaching the mailing list. did you > register for it? > > I'm not sure what could be causing this problem. We have a demo that comes > with freeglut that does menus (one is its name) and this works fine on my > windows machine. One difference I see between that demo and your code is > that the menus are created before the window is opened, but that really > shouldn't matter. > Could you track down the one demo in your distribution of freeglut 2.8 and > try if that works? > > Are you using Fedora yourself as well? > > Best, > Dee > > On Tue, Jun 19, 2012 at 1:24 AM, Manfred Spraul > <ma...@co...>wrote: > >> Hi, >> >> I know that it is impolite to send personal mails, but it seems that I >> can't post to the freeglut-developer list :-( >> >> Do you have any idea what could be causing the problem described below? >> Feel free to forward the mail to the mailing list. >> >> -- >> Manfred >> >> >> -------- Original Message -------- Subject: incompatibility between >> freeglut-2.6 and freeglut-2.8 with menus Date: Sun, 17 Jun 2012 14:12:33 >> +0200 From: Manfred Spraul >> <ma...@co...><ma...@co...> To: >> fre...@li... >> >> Hi, >> >> I've observed that the (popup) menu from cgx stopped working after >> upgrading from freeglut-2.6 to freeglut-2.8. >> The code works with glut-3.5, freeglut-2.4, freeglut-2.6. >> With freeglut-2.8 it stopped working. >> I've tested with freeglut-2.8.0 from Fedora FC17. >> As far as I can see, it's based onfreeglut-2.8.0.tar.gz from Jan 2012 >> without any changes. >> (1 patch that affects the -L flags for the demos) >> >> Are there any known bugs? >> Are any special initializations required? >> >> Attached is a test case: freeglut-2.6 shows a menu, freeglut-2.8 doesn't. >> The full cgx source code is available from >> http://calculix-rpm.sourceforge.net/ >> >> -- >> Manfred >> >> >> >> >> >> > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Diederick C. N. <dc...@gm...> - 2012-06-21 04:33:28
|
Hi Ioannis, On Tue, Jun 19, 2012 at 9:56 PM, <ipe...@it...> wrote: > I have the same problem with Manfred in Windows XP. > Experimenting, I have noticed that menus don't appear if an entry > callback is defined with glutEntryFunc. > If we don't define this one, the menus appear normally. Thanks for the report. That's one I should be able to look into (not very soon though, there is a move going on here). Let me find out if i can reproduce it on Windows 7 (thats all I have reliable access to). Best, Dee |
From: Diederick C. N. <dc...@gm...> - 2012-06-21 04:31:50
|
Dear Manfred, John T, On Thu, Jun 21, 2012 at 4:19 AM, Manfred Spraul <ma...@co...> wrote: > Hi Dee, > > I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. > After downgrading the dynamic library, the same binary works. That is a very troubling report! Right now I am not sure what might have changed to the menu code between 2.6.0 and 2.8.0 (its a two year interval), nor am I familiar with the Linux side of things... John T, could you try the one demo and see if the menu's work (after pressing escape to leave game mode)? Then we'll know if this is reproducible. Thanks! Dee |
From: John T. <nu...@me...> - 2012-06-21 23:36:41
|
On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster wrote: > > I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. > > After downgrading the dynamic library, the same binary works. > > That is a very troubling report! Right now I am not sure what might > have changed to the menu code between 2.6.0 and 2.8.0 (its a two year > interval), nor am I familiar with the Linux side of things... > > John T, could you try the one demo and see if the menu's work (after > pressing escape to leave game mode)? Then we'll know if this is > reproducible. Aha! evidently they don't! I even tried the single program I *ever* wrote where I used glut menus, and it doesn't work there either. So it's not something wrong with the demo. That nobody noticed until now, says something about the pointlessness of glut menus I think :) -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. F. <joh...@cy...> - 2012-06-23 21:58:54
|
On Windows 7 with MSVC 6.0 I get the following behavior when I add the entry callback to the first window: Click in the first window: no menu. The entry function is called. Click in the second window: a menu appears. The entry function is not called. Click in the first window: the menu moves to the first window. I don't know if it's reopening the menu or just moving the already-open menu. The entry function is not called. Click in the first window again: no menu. The entry function is called. It's highly repeatable. - John F. On 6/21/2012 6:36 PM, John Tsiombikas wrote: > On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster wrote: > >>> I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. >>> After downgrading the dynamic library, the same binary works. >>> >> That is a very troubling report! Right now I am not sure what might >> have changed to the menu code between 2.6.0 and 2.8.0 (its a two year >> interval), nor am I familiar with the Linux side of things... >> >> John T, could you try the one demo and see if the menu's work (after >> pressing escape to leave game mode)? Then we'll know if this is >> reproducible. >> > Aha! evidently they don't! I even tried the single program I *ever* > wrote where I used glut menus, and it doesn't work there either. So it's > not something wrong with the demo. > > That nobody noticed until now, says something about the pointlessness of > glut menus I think :) > > |
From: John F. F. <joh...@cy...> - 2012-06-24 04:15:32
|
OK ... SVN version 835 works properly but does not bring up full-screen properly. SVN version 836 does not work properly and does not bring up full-screen properly. Let me look some more tomorrow. - John F. On 6/23/2012 4:58 PM, John F. Fay wrote: > On Windows 7 with MSVC 6.0 I get the following behavior when I add the > entry callback to the first window: > > Click in the first window: no menu. The entry function is called. > Click in the second window: a menu appears. The entry function is > not called. > Click in the first window: the menu moves to the first window. I > don't know if it's reopening the menu or just moving the already-open > menu. The entry function is not called. > Click in the first window again: no menu. The entry function is called. > > It's highly repeatable. > > - John F. > > > On 6/21/2012 6:36 PM, John Tsiombikas wrote: >> On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster wrote: >>>> I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. >>>> After downgrading the dynamic library, the same binary works. >>> That is a very troubling report! Right now I am not sure what might >>> have changed to the menu code between 2.6.0 and 2.8.0 (its a two year >>> interval), nor am I familiar with the Linux side of things... >>> >>> John T, could you try the one demo and see if the menu's work (after >>> pressing escape to leave game mode)? Then we'll know if this is >>> reproducible. >> Aha! evidently they don't! I even tried the single program I *ever* >> wrote where I used glut menus, and it doesn't work there either. So it's >> not something wrong with the demo. >> >> That nobody noticed until now, says something about the pointlessness of >> glut menus I think :) >> |
From: John F. F. <joh...@cy...> - 2012-06-24 04:22:21
|
I think this is the offending code, from "freeglut_main.c" around line 1675 in the Windows event handler: WORKS: #if 0 case WM_SETFOCUS: /* printf("WM_SETFOCUS: %p\n", window ); */ lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); break; case WM_ACTIVATE: if (LOWORD(wParam) != WA_INACTIVE) { /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, window->State.Cursor ); */ fgSetCursor( window, window->State.Cursor ); } lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); break; #endif DOESN'T WORK: case WM_SETFOCUS: /* printf("WM_SETFOCUS: %p\n", window ); */ lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); INVOKE_WCB( *window, Entry, ( GLUT_ENTERED ) ); break; case WM_KILLFOCUS: /* printf("WM_KILLFOCUS: %p\n", window ); */ lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); if( window->IsMenu && window->ActiveMenu && window->ActiveMenu->IsActive ) fgUpdateMenuHighlight( window->ActiveMenu ); break; #if 0 case WM_ACTIVATE: if (LOWORD(wParam) != WA_INACTIVE) { /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, window->State.Cursor ); */ fgSetCursor( window, window->State.Cursor ); } lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); break; #endif On 6/23/2012 11:15 PM, John F. Fay wrote: > OK ... > > SVN version 835 works properly but does not bring up full-screen > properly. > SVN version 836 does not work properly and does not bring up > full-screen properly. > > Let me look some more tomorrow. > > - John F. > > > On 6/23/2012 4:58 PM, John F. Fay wrote: >> On Windows 7 with MSVC 6.0 I get the following behavior when I add >> the entry callback to the first window: >> >> Click in the first window: no menu. The entry function is called. >> Click in the second window: a menu appears. The entry function is >> not called. >> Click in the first window: the menu moves to the first window. I >> don't know if it's reopening the menu or just moving the already-open >> menu. The entry function is not called. >> Click in the first window again: no menu. The entry function is >> called. >> >> It's highly repeatable. >> >> - John F. >> >> >> On 6/21/2012 6:36 PM, John Tsiombikas wrote: >>> On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster >>> wrote: >>>>> I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. >>>>> After downgrading the dynamic library, the same binary works. >>>> That is a very troubling report! Right now I am not sure what might >>>> have changed to the menu code between 2.6.0 and 2.8.0 (its a two year >>>> interval), nor am I familiar with the Linux side of things... >>>> >>>> John T, could you try the one demo and see if the menu's work (after >>>> pressing escape to leave game mode)? Then we'll know if this is >>>> reproducible. >>> Aha! evidently they don't! I even tried the single program I *ever* >>> wrote where I used glut menus, and it doesn't work there either. So >>> it's >>> not something wrong with the demo. >>> >>> That nobody noticed until now, says something about the >>> pointlessness of >>> glut menus I think :) >>> |
From: Diederick C. N. <dc...@gm...> - 2012-06-24 07:21:06
|
Hi John, Thats a quick dissection, thanks! I might not get to it in the next week because of a move, but i hope i can figure this out further. Should you find the time, feel free to make the changes you think are best and commit them of course! Best and thanks a lot! Dee On Sun, Jun 24, 2012 at 12:22 PM, John F. Fay <joh...@cy...> wrote: > I think this is the offending code, from "freeglut_main.c" around line > 1675 in the Windows event handler: > > WORKS: > #if 0 > case WM_SETFOCUS: > /* printf("WM_SETFOCUS: %p\n", window ); */ > lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); > break; > > case WM_ACTIVATE: > if (LOWORD(wParam) != WA_INACTIVE) > { > /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, > window->State.Cursor ); */ > fgSetCursor( window, window->State.Cursor ); > } > > lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); > break; > #endif > > > > DOESN'T WORK: > case WM_SETFOCUS: > /* printf("WM_SETFOCUS: %p\n", window ); */ > lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); > INVOKE_WCB( *window, Entry, ( GLUT_ENTERED ) ); > break; > > case WM_KILLFOCUS: > /* printf("WM_KILLFOCUS: %p\n", window ); */ > lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); > INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); > > if( window->IsMenu && > window->ActiveMenu && window->ActiveMenu->IsActive ) > fgUpdateMenuHighlight( window->ActiveMenu ); > > break; > > #if 0 > case WM_ACTIVATE: > if (LOWORD(wParam) != WA_INACTIVE) > { > /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, > window->State.Cursor ); */ > fgSetCursor( window, window->State.Cursor ); > } > > lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); > break; > #endif > > > > > > > On 6/23/2012 11:15 PM, John F. Fay wrote: >> OK ... >> >> SVN version 835 works properly but does not bring up full-screen >> properly. >> SVN version 836 does not work properly and does not bring up >> full-screen properly. >> >> Let me look some more tomorrow. >> >> - John F. >> >> >> On 6/23/2012 4:58 PM, John F. Fay wrote: >>> On Windows 7 with MSVC 6.0 I get the following behavior when I add >>> the entry callback to the first window: >>> >>> Click in the first window: no menu. The entry function is called. >>> Click in the second window: a menu appears. The entry function is >>> not called. >>> Click in the first window: the menu moves to the first window. I >>> don't know if it's reopening the menu or just moving the already-open >>> menu. The entry function is not called. >>> Click in the first window again: no menu. The entry function is >>> called. >>> >>> It's highly repeatable. >>> >>> - John F. >>> >>> >>> On 6/21/2012 6:36 PM, John Tsiombikas wrote: >>>> On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster >>>> wrote: >>>>>> I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. >>>>>> After downgrading the dynamic library, the same binary works. >>>>> That is a very troubling report! Right now I am not sure what might >>>>> have changed to the menu code between 2.6.0 and 2.8.0 (its a two year >>>>> interval), nor am I familiar with the Linux side of things... >>>>> >>>>> John T, could you try the one demo and see if the menu's work (after >>>>> pressing escape to leave game mode)? Then we'll know if this is >>>>> reproducible. >>>> Aha! evidently they don't! I even tried the single program I *ever* >>>> wrote where I used glut menus, and it doesn't work there either. So >>>> it's >>>> not something wrong with the demo. >>>> >>>> That nobody noticed until now, says something about the >>>> pointlessness of >>>> glut menus I think :) >>>> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: John F. F. <joh...@cy...> - 2012-06-24 13:17:11
|
Here's the log message for the change: "Implementing "glutEntryFunc" for Windows properly. I also moved the menu highlight code so that needs checking." And the offending line of code is in the "WM_KILLFOCUS" block: INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); Comment out that line of code and the menu appears. The "glutEntry" callback doesn't get invoked, though. So now we need to figure out why invoking the "glutEntry" callback stops the menu from being displayed. - John F. On 6/24/2012 2:20 AM, Diederick C. Niehorster wrote: > Hi John, > > Thats a quick dissection, thanks! I might not get to it in the next > week because of a move, but i hope i can figure this out further. > Should you find the time, feel free to make the changes you think are > best and commit them of course! > > Best and thanks a lot! > Dee > > On Sun, Jun 24, 2012 at 12:22 PM, John F. Fay<joh...@cy...> wrote: > >> I think this is the offending code, from "freeglut_main.c" around line >> 1675 in the Windows event handler: >> >> WORKS: >> #if 0 >> case WM_SETFOCUS: >> /* printf("WM_SETFOCUS: %p\n", window ); */ >> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >> break; >> >> case WM_ACTIVATE: >> if (LOWORD(wParam) != WA_INACTIVE) >> { >> /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, >> window->State.Cursor ); */ >> fgSetCursor( window, window->State.Cursor ); >> } >> >> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >> break; >> #endif >> >> >> >> DOESN'T WORK: >> case WM_SETFOCUS: >> /* printf("WM_SETFOCUS: %p\n", window ); */ >> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >> INVOKE_WCB( *window, Entry, ( GLUT_ENTERED ) ); >> break; >> >> case WM_KILLFOCUS: >> /* printf("WM_KILLFOCUS: %p\n", window ); */ >> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >> INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); >> >> if( window->IsMenu&& >> window->ActiveMenu&& window->ActiveMenu->IsActive ) >> fgUpdateMenuHighlight( window->ActiveMenu ); >> >> break; >> >> #if 0 >> case WM_ACTIVATE: >> if (LOWORD(wParam) != WA_INACTIVE) >> { >> /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, >> window->State.Cursor ); */ >> fgSetCursor( window, window->State.Cursor ); >> } >> >> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >> break; >> #endif >> >> >> >> >> >> >> On 6/23/2012 11:15 PM, John F. Fay wrote: >> >>> OK ... >>> >>> SVN version 835 works properly but does not bring up full-screen >>> properly. >>> SVN version 836 does not work properly and does not bring up >>> full-screen properly. >>> >>> Let me look some more tomorrow. >>> >>> - John F. >>> >>> >>> On 6/23/2012 4:58 PM, John F. Fay wrote: >>> >>>> On Windows 7 with MSVC 6.0 I get the following behavior when I add >>>> the entry callback to the first window: >>>> >>>> Click in the first window: no menu. The entry function is called. >>>> Click in the second window: a menu appears. The entry function is >>>> not called. >>>> Click in the first window: the menu moves to the first window. I >>>> don't know if it's reopening the menu or just moving the already-open >>>> menu. The entry function is not called. >>>> Click in the first window again: no menu. The entry function is >>>> called. >>>> >>>> It's highly repeatable. >>>> >>>> - John F. >>>> >>>> >>>> On 6/21/2012 6:36 PM, John Tsiombikas wrote: >>>> >>>>> On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster >>>>> wrote: >>>>> >>>>>>> I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. >>>>>>> After downgrading the dynamic library, the same binary works. >>>>>>> >>>>>> That is a very troubling report! Right now I am not sure what might >>>>>> have changed to the menu code between 2.6.0 and 2.8.0 (its a two year >>>>>> interval), nor am I familiar with the Linux side of things... >>>>>> >>>>>> John T, could you try the one demo and see if the menu's work (after >>>>>> pressing escape to leave game mode)? Then we'll know if this is >>>>>> reproducible. >>>>>> >>>>> Aha! evidently they don't! I even tried the single program I *ever* >>>>> wrote where I used glut menus, and it doesn't work there either. So >>>>> it's >>>>> not something wrong with the demo. >>>>> >>>>> That nobody noticed until now, says something about the >>>>> pointlessness of >>>>> glut menus I think :) >>>>> >>>>> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: <ipe...@it...> - 2012-06-24 22:50:42
|
Dear John F, I noticed that WM_SETFOCUS is activated if you pass the mouse over the window. Normally, I would expect this event after a click inside the window. This feels like the window is stealing the focus. Then I saw that in WM_MOUSEMOVE there is a SetFocus. Is that really necessary? Ioannis Quoting "John F. Fay" <joh...@cy...>: > Here's the log message for the change: > > "Implementing "glutEntryFunc" for Windows properly. I also moved the > menu highlight code so that needs checking." > > And the offending line of code is in the "WM_KILLFOCUS" block: > > INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); > > Comment out that line of code and the menu appears. The "glutEntry" > callback doesn't get invoked, though. So now we need to figure out > why invoking the "glutEntry" callback stops the menu from being > displayed. > > - John F. > > > > > On 6/24/2012 2:20 AM, Diederick C. Niehorster wrote: >> Hi John, >> >> Thats a quick dissection, thanks! I might not get to it in the next >> week because of a move, but i hope i can figure this out further. >> Should you find the time, feel free to make the changes you think are >> best and commit them of course! >> >> Best and thanks a lot! >> Dee >> >> On Sun, Jun 24, 2012 at 12:22 PM, John F. >> Fay<joh...@cy...> wrote: >> >>> I think this is the offending code, from "freeglut_main.c" around line >>> 1675 in the Windows event handler: >>> >>> WORKS: >>> #if 0 >>> case WM_SETFOCUS: >>> /* printf("WM_SETFOCUS: %p\n", window ); */ >>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>> break; >>> >>> case WM_ACTIVATE: >>> if (LOWORD(wParam) != WA_INACTIVE) >>> { >>> /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, >>> window->State.Cursor ); */ >>> fgSetCursor( window, window->State.Cursor ); >>> } >>> >>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>> break; >>> #endif >>> >>> >>> >>> DOESN'T WORK: >>> case WM_SETFOCUS: >>> /* printf("WM_SETFOCUS: %p\n", window ); */ >>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>> INVOKE_WCB( *window, Entry, ( GLUT_ENTERED ) ); >>> break; >>> >>> case WM_KILLFOCUS: >>> /* printf("WM_KILLFOCUS: %p\n", window ); */ >>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>> INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); >>> >>> if( window->IsMenu&& >>> window->ActiveMenu&& window->ActiveMenu->IsActive ) >>> fgUpdateMenuHighlight( window->ActiveMenu ); >>> >>> break; >>> >>> #if 0 >>> case WM_ACTIVATE: >>> if (LOWORD(wParam) != WA_INACTIVE) >>> { >>> /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, >>> window->State.Cursor ); */ >>> fgSetCursor( window, window->State.Cursor ); >>> } >>> >>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>> break; >>> #endif >>> >>> >>> >>> >>> >>> >>> On 6/23/2012 11:15 PM, John F. Fay wrote: >>> >>>> OK ... >>>> >>>> SVN version 835 works properly but does not bring up full-screen >>>> properly. >>>> SVN version 836 does not work properly and does not bring up >>>> full-screen properly. >>>> >>>> Let me look some more tomorrow. >>>> >>>> - John F. >>>> >>>> >>>> On 6/23/2012 4:58 PM, John F. Fay wrote: >>>> >>>>> On Windows 7 with MSVC 6.0 I get the following behavior when I add >>>>> the entry callback to the first window: >>>>> >>>>> Click in the first window: no menu. The entry function is called. >>>>> Click in the second window: a menu appears. The entry function is >>>>> not called. >>>>> Click in the first window: the menu moves to the first window. I >>>>> don't know if it's reopening the menu or just moving the already-open >>>>> menu. The entry function is not called. >>>>> Click in the first window again: no menu. The entry function is >>>>> called. >>>>> >>>>> It's highly repeatable. >>>>> >>>>> - John F. >>>>> >>>>> >>>>> On 6/21/2012 6:36 PM, John Tsiombikas wrote: >>>>> >>>>>> On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster >>>>>> wrote: >>>>>> >>>>>>>> I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. >>>>>>>> After downgrading the dynamic library, the same binary works. >>>>>>>> >>>>>>> That is a very troubling report! Right now I am not sure what might >>>>>>> have changed to the menu code between 2.6.0 and 2.8.0 (its a two year >>>>>>> interval), nor am I familiar with the Linux side of things... >>>>>>> >>>>>>> John T, could you try the one demo and see if the menu's work (after >>>>>>> pressing escape to leave game mode)? Then we'll know if this is >>>>>>> reproducible. >>>>>>> >>>>>> Aha! evidently they don't! I even tried the single program I *ever* >>>>>> wrote where I used glut menus, and it doesn't work there either. So >>>>>> it's >>>>>> not something wrong with the demo. >>>>>> >>>>>> That nobody noticed until now, says something about the >>>>>> pointlessness of >>>>>> glut menus I think :) >>>>>> >>>>>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Freeglut-developer mailing list >>> Fre...@li... >>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >>> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <ipe...@it...> - 2012-06-25 07:10:31
|
I think I found the problem on MS Windows. In glutPopWindow (freeglut_window.c, line 1941 approx.) we need to add one more flag: SWP_SHOWWINDOW. void FGAPIENTRY glutPopWindow( void ) { .. SetWindowPos( fgStructure.CurrentWindow->Window.Handle, HWND_TOP, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_SHOWWINDOW ); .. } This doesn't seem to be related to glutEntryFunc but the latter somehow affects its behaviour. I recompiled the library and tested "one.c" on Windows XP SP3 and works fine. I also tested it on Windows 7 SP1 where it works fine when we have the two windows, but when in full screen mode and press the button, the screen goes black for half a sec instead of displaying the menu Hope this helps Ioannis ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: John F. F. <joh...@cy...> - 2012-06-26 02:44:07
|
OK, what about the other five places that the "SWP_NOMOVE | SWP_NOSIZE" flags are set? Two of them are in "fgPlatformOpenWindow", one is in "fgPlatformGlutPushWindow", one is in "fgPlatformGlutFullScreen", and one is in "fgPlatformGlutLeaveFullScreen" (to use the current function names). - John F. On 6/25/2012 2:10 AM, ipe...@it... wrote: > I think I found the problem on MS Windows. > In glutPopWindow (freeglut_window.c, line 1941 approx.) we need to add > one more flag: SWP_SHOWWINDOW. > void FGAPIENTRY glutPopWindow( void ) > { > .. > SetWindowPos( > fgStructure.CurrentWindow->Window.Handle, > HWND_TOP, > 0, 0, 0, 0, > SWP_NOSIZE | SWP_NOMOVE | SWP_SHOWWINDOW > ); > .. > } > This doesn't seem to be related to glutEntryFunc but the latter > somehow affects its behaviour. > I recompiled the library and tested "one.c" on Windows XP SP3 and works fine. > I also tested it on Windows 7 SP1 where it works fine when we have the > two windows, but when in full screen mode and press the button, the > screen goes black for half a sec instead of displaying the menu > Hope this helps > Ioannis > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: Diederick C. N. <dc...@gm...> - 2012-06-26 03:26:07
|
Hi Guys, Making progress! (Note that this does not at all address the X11 problems of course) On Tue, Jun 26, 2012 at 10:43 AM, John F. Fay <joh...@cy...> wrote: > OK, what about the other five places that the "SWP_NOMOVE | SWP_NOSIZE" > flags are set? Two of them are in "fgPlatformOpenWindow", one is in > "fgPlatformGlutPushWindow", one is in "fgPlatformGlutFullScreen", and > one is in "fgPlatformGlutLeaveFullScreen" (to use the current function > names). I remember when working on these functions, I did not change those flags as I'm not sure what each does... That'd probably be the first thing to do when adressing this, so we can assess what should be needed at each plane in the code. http://msdn.microsoft.com/en-us/library/windows/desktop/ms633545(v=vs.85).aspx It seems that "fgPlatformGlutPushWindow" should definately not add this flag, as we're hiding a window. It should probably get SWP_HIDEWINDOW. Otherwise, adding the flag should be fine. But a second opinion would be nice! SWP_NOACTIVATE is also one to look into. The sentence in remarls "If you have changed certain window data using SetWindowLong, you must call SetWindowPos for the changes to take effect" is also somehting to look into, make sure we do this consistently. Later. > > On 6/25/2012 2:10 AM, ipe...@it... wrote: >> I recompiled the library and tested "one.c" on Windows XP SP3 and works fine. >> I also tested it on Windows 7 SP1 where it works fine when we have the >> two windows, but when in full screen mode and press the button, the >> screen goes black for half a sec instead of displaying the menu This demo uses not just a fullscreen mode, it is the so-called game mode. Menus are not available in that mode as the gamemode is a TOPMOST window. I'm not sure how we compare to GLUT in this (though i do know GLUT gives a hard error when trying to open a child window while in gamemode, never tried menus though), so i don't know whether we should simply suppress the attempt to open a menu when in gamemode (with a warning to the console probably) or whether we should aim to make it work. I can have a look at what the desired behavior is. On Mon, Jun 25, 2012 at 6:50 AM, <ipe...@it...> wrote: > I noticed that WM_SETFOCUS is activated if you pass the mouse over the window. > Normally, I would expect this event after a click inside the window. > This feels like the window is stealing the focus. > Then I saw that in WM_MOUSEMOVE there is a SetFocus. > Is that really necessary? Another good thing to spot. I also noted in the demos that whatever window currently has the mouse on it jumps forward, which, for Windows at least, is rather nonstandard behavior. Good spot, i never thought too much of it. Lets deal with these 3+ issues in top-to-bottom order. Best, Dee |
From: <ipe...@it...> - 2012-06-26 04:57:36
|
Hi Guys, > Making progress! (Note that this does not at all address the X11 > problems of course) I don't have access to a linux machine so all i can do is try to investigate the MS WIndows part. >> OK, what about the other five places that the "SWP_NOMOVE | SWP_NOSIZE" >> flags are set? Two of them are in "fgPlatformOpenWindow", one is in >> "fgPlatformGlutPushWindow", one is in "fgPlatformGlutFullScreen", and >> one is in "fgPlatformGlutLeaveFullScreen" (to use the current function >> names). You are right, it's strange to me too. While i was searching the problem yesterday i ended up to the conclusion that the menu window doesn't get a WM_PAINT event. As far as i understand the only place where we ask for redraw is using the SetWindowPos. Therefore i tried the flag and it worked. If this is the case, then we are dealing with MS-Windows inconsistent behaviour or at least inadequate documentation. On the other hand, maybe i am missing something. I'll try again today to figure out what happens. Regards Ioannis ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <ipe...@it...> - 2012-06-26 07:03:59
|
Hi again, this time i think we found the bug. Our first assumption that Entry is causing the problem was correct. In WM_KILLFOCUS we have case WM_KILLFOCUS: lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); if( window->IsMenu && window->ActiveMenu && window->ActiveMenu->IsActive ) { fgUpdateMenuHighlight( window->ActiveMenu ); } break; If we expand the macro INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); we get something like: if ( (*window).CallBacks[CB_Entry] ) { FGCBEntry func=(FGCBEntry)((*window).CallBacks[CB_Entry]); fgSetWindow( window ); func(GLUT_LEFT); } the problem is "fgSetWindow( window );" which changes the current window. We must save the current window and after "Entry" restore it. We should write something like: case WM_KILLFOCUS: lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); SFG_Window *last_window=fgStructure.CurrentWindow; INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); fgSetWindow( last_window ); if( window->IsMenu && window->ActiveMenu && window->ActiveMenu->IsActive ) { fgUpdateMenuHighlight( window->ActiveMenu ); } break; As usual, i recompiled the library (gcc 3.4.2 from DEV C++) and tested on Windows XP SP3 and Windows 7 SP1. It seems to be working without any problems. On Windows XP the menus work even in GameMode (as i mentioned yesterday). Apparently this has nothing to do with SWP_SHOWWINDOW, so we probably no longer need to investigate the flags. On the other hand, we should be alarmed that invoking a callback somewhere else, when playing with different windows, might be causing a similar problem. Hopefully, this solves the problem in X11 too. Someone please try it and give us feedback. Regards Ioannis ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Jason W. <jas...@gm...> - 2012-07-14 05:25:53
|
No need for the global function to save and restore, or a stack. Just use the local scope created in the macro to store the value in each place where it is needed. #if TARGET_HOST_MS_WINDOWS && !defined(_WIN32_WCE) /* FIXME: also WinCE? */ #define INVOKE_WCB(window,cbname,arg_list) \ do \ { \ if( FETCH_WCB( window, cbname ) ) \ { \ SFG_Window *_saved_window; \ FGCB ## cbname func = (FGCB ## cbname)(FETCH_WCB( window, cbname )); \ _saved_window = fgStructure.CurrentWindow; \ fgSetWindow( &window ); \ func arg_list; \ fgStructure.CurrentWindow = _saved_window; \ } \ } while( 0 ) #else #define INVOKE_WCB(window,cbname,arg_list) \ do \ { \ if( FETCH_WCB( window, cbname ) ) \ { \ SFG_Window *_saved_window; \ _saved_window = fgStructure.CurrentWindow; \ fgSetWindow( &window ); \ ((FGCB ## cbname)FETCH_WCB( window, cbname )) arg_list; \ fgStructure.CurrentWindow = _saved_window; \ } \ } while( 0 ) #endif On Tue, Jun 26, 2012 at 2:03 AM, <ipe...@it...> wrote: > Hi again, > this time i think we found the bug. > Our first assumption that Entry is causing the problem was correct. > > In WM_KILLFOCUS we have > > case WM_KILLFOCUS: > lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); > INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); > if( window->IsMenu && window->ActiveMenu && > window->ActiveMenu->IsActive ) > { > fgUpdateMenuHighlight( window->ActiveMenu ); > } > break; > > If we expand the macro INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); > we get something like: > if ( (*window).CallBacks[CB_Entry] ) > { > FGCBEntry func=(FGCBEntry)((*window).CallBacks[CB_Entry]); > fgSetWindow( window ); > func(GLUT_LEFT); > } > the problem is "fgSetWindow( window );" which changes the current window. > We must save the current window and after "Entry" restore it. > We should write something like: > case WM_KILLFOCUS: > lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); > > SFG_Window *last_window=fgStructure.CurrentWindow; > INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); > fgSetWindow( last_window ); > > if( window->IsMenu && window->ActiveMenu && > window->ActiveMenu->IsActive ) > { > fgUpdateMenuHighlight( window->ActiveMenu ); > } > break; > > As usual, i recompiled the library (gcc 3.4.2 from DEV C++) and tested > on Windows XP SP3 and Windows 7 SP1. > It seems to be working without any problems. On Windows XP the menus > work even in GameMode (as i mentioned yesterday). > > Apparently this has nothing to do with SWP_SHOWWINDOW, so we probably > no longer need to investigate the flags. > On the other hand, we should be alarmed that invoking a callback > somewhere else, when playing with different windows, might be causing > a similar problem. > > Hopefully, this solves the problem in X11 too. > Someone please try it and give us feedback. > > Regards > Ioannis > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: <ipe...@it...> - 2012-06-26 15:31:55
|
Hi again, It seems that this fgSetWindow() inside the macro indeed causes problems. For instance i run into the following problem: If we create our main window with glutCreateWindow(), define an entry callback and then create a menu with glutCreateMenu(), the main window doesn't draw its contents for the first time unless we call glutPostRedisplay. This happens because somewhere in the middle of glutCreateMenu() a glutHideWindow() (for the menu) is called which calls a ShowWindow(..., SW_HIDE) and this invokes the Entry callback which sets the current_window to the main window. After that, inside HideWindow(), the variable fgStructure.CurrentWindow->State.Redisplay is reset to GL_FALSE but the fgStructure.CurrentWindow is now the main window and so it doesn't call its Display function. I think the proper way to solve this problem is to modify the INVOKE_WCB macro to save the current window before calling fgSetWindow and restrore after calling the callback It could be something like: In "freeglut_window.c" define a static variable and two functions static SFG_Window *_saved_window=NULL; void _fgSaveCurrentWindow() { _saved_window=fgStructure.CurrentWindow; } void _fgRestoreCurrentWindow() { fgStructure.CurrentWindow=_saved_window; } and then in "freeglut_internal.h" modify the macro: void _fgSaveCurrentWindow(); void _fgRestoreCurrentWindow(); #if TARGET_HOST_MS_WINDOWS && !defined(_WIN32_WCE) /* FIXME: also WinCE? */ #define INVOKE_WCB(window,cbname,arg_list) \ do \ { \ if( FETCH_WCB( window, cbname ) ) \ { \ FGCB ## cbname func = (FGCB ## cbname)(FETCH_WCB( window, cbname )); \ _fgSaveCurrentWindow(); \ fgSetWindow( &window ); \ func arg_list; \ _fgRestoreCurrentWindow(); \ } \ } while( 0 ) #else #define INVOKE_WCB(window,cbname,arg_list) \ do \ { \ if( FETCH_WCB( window, cbname ) ) \ { \ _fgSaveCurrentWindow(); \ fgSetWindow( &window ); \ ((FGCB ## cbname)FETCH_WCB( window, cbname )) arg_list; \ _fgRestoreCurrentWindow(); \ } \ } while( 0 ) #endif Or even better, it could be a stack of a finite number of, say 10, window pointers, to allow for subsequent saves and restores. #define MAX_SAVED_WINDOWS 10 static int _top_saved_window=0; static SFG_Window *_saved_window[MAX_SAVED_WINDOWS]; void _fgSaveCurrentWindow() { if (_top_saved_window==MAX_SAVED_WINDOWS) { // warning } else _saved_window[_top_saved_window++]=fgStructure.CurrentWindow; } void _fgRestoreCurrentWindow() { if (_top_saved_window==0) { // warning } else fgStructure.CurrentWindow=_saved_window[--_top_saved_window]; } I think this would solve the problem permanently. Regards Ioannis ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Diederick C. N. <dc...@gm...> - 2012-06-27 08:21:59
|
Hi Ioannis, thank you for the investigation and suggestions (and cool that menus actually work in gamemode with your fixes! No need to see what glut does then, having them always work is a good thing). This is a change with potentially big consequences tho, especially due to the hard to follow sequence of events on windows. So we have to be careful implementing this (our demos/tests dont by far cover all functionality). John F, how do you feel about the proposed? And maybe trying to clean up some call sequences. E.g. Previously it ws suggested to do a reshape immediately instead of only when the window is redisplayed. There might be other places that can be simplified and clarified. If you're busy, maybe, if you have any, you could share some initial thoughts about the proposed? Thanks both! Dee On 6/26/12, ipe...@it... <ipe...@it...> wrote: > Hi again, > It seems that this fgSetWindow() inside the macro indeed causes problems. > For instance i run into the following problem: > If we create our main window with glutCreateWindow(), define an entry > callback and then create a menu with glutCreateMenu(), the main window > doesn't draw its > contents for the first time unless we call glutPostRedisplay. > This happens because somewhere in the middle of glutCreateMenu() a > glutHideWindow() (for the menu) is called which calls a ShowWindow(..., > SW_HIDE) and this invokes the Entry callback which sets the current_window > to > the main window. > After that, inside HideWindow(), the variable > fgStructure.CurrentWindow->State.Redisplay is reset to GL_FALSE but > the fgStructure.CurrentWindow is now the main window and so it doesn't > call its Display function. > > I think the proper way to solve this problem is to modify the > INVOKE_WCB macro to save the current window before calling fgSetWindow > and restrore after calling the callback > > It could be something like: > > In "freeglut_window.c" define a static variable and two functions > static SFG_Window *_saved_window=NULL; > void _fgSaveCurrentWindow() > { > _saved_window=fgStructure.CurrentWindow; > } > void _fgRestoreCurrentWindow() > { > fgStructure.CurrentWindow=_saved_window; > } > > and then in "freeglut_internal.h" modify the macro: > > void _fgSaveCurrentWindow(); > void _fgRestoreCurrentWindow(); > > #if TARGET_HOST_MS_WINDOWS && !defined(_WIN32_WCE) /* FIXME: also WinCE? */ > #define INVOKE_WCB(window,cbname,arg_list) \ > do \ > { \ > if( FETCH_WCB( window, cbname ) ) \ > { \ > FGCB ## cbname func = (FGCB ## cbname)(FETCH_WCB( window, cbname > )); \ > _fgSaveCurrentWindow(); \ > fgSetWindow( &window ); \ > func arg_list; \ > _fgRestoreCurrentWindow(); \ > } \ > } while( 0 ) > #else > #define INVOKE_WCB(window,cbname,arg_list) \ > do \ > { \ > if( FETCH_WCB( window, cbname ) ) \ > { \ > _fgSaveCurrentWindow(); \ > fgSetWindow( &window ); \ > ((FGCB ## cbname)FETCH_WCB( window, cbname )) arg_list; \ > _fgRestoreCurrentWindow(); \ > } \ > } while( 0 ) > #endif > > Or even better, it could be a stack of a finite number of, say 10, > window pointers, to allow for subsequent saves and restores. > > #define MAX_SAVED_WINDOWS 10 > static int _top_saved_window=0; > static SFG_Window *_saved_window[MAX_SAVED_WINDOWS]; > void _fgSaveCurrentWindow() > { > if (_top_saved_window==MAX_SAVED_WINDOWS) > { > // warning > } > else > _saved_window[_top_saved_window++]=fgStructure.CurrentWindow; > } > void _fgRestoreCurrentWindow() > { > if (_top_saved_window==0) > { > // warning > } > else > fgStructure.CurrentWindow=_saved_window[--_top_saved_window]; > } > > I think this would solve the problem permanently. > > Regards > Ioannis > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |
From: <ipe...@it...> - 2012-06-27 10:58:31
|
Hi Dee, just for the records: If you try to attach a menu in gamemode in GLUT you get the message: "cannot attach menus in game mode". I think this is probably because GLUT uses the Win32 API popup menus which i assume don't work in DOS mode. In FREEGLUT though, menus are independent windows, so probably they can be made to work. Ioannis ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Manfred S. <ma...@co...> - 2012-07-08 21:43:29
Attachments:
freeglut-2.8.0-fixmenu.patch
|
Hi, just as a feedback for Linux: I tried the described fix, but it didn't help (patch attached). Any ideas how to debug the issue? Save & restore of the current window in INVOKE_WCB does not fix the missing menu :-( -- Manfred |
From: Jason W. <jas...@gm...> - 2012-07-14 05:27:43
|
Commenting out this SetFocus solved the problem of windows being activated on mouse over. I'm not sure what the purpose of that code was. On Sun, Jun 24, 2012 at 5:50 PM, <ipe...@it...> wrote: > Dear John F, > I noticed that WM_SETFOCUS is activated if you pass the mouse over the window. > Normally, I would expect this event after a click inside the window. > This feels like the window is stealing the focus. > Then I saw that in WM_MOUSEMOVE there is a SetFocus. > Is that really necessary? > > Ioannis > > > > Quoting "John F. Fay" <joh...@cy...>: > >> Here's the log message for the change: >> >> "Implementing "glutEntryFunc" for Windows properly. I also moved the >> menu highlight code so that needs checking." >> >> And the offending line of code is in the "WM_KILLFOCUS" block: >> >> INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); >> >> Comment out that line of code and the menu appears. The "glutEntry" >> callback doesn't get invoked, though. So now we need to figure out >> why invoking the "glutEntry" callback stops the menu from being >> displayed. >> >> - John F. >> >> >> >> >> On 6/24/2012 2:20 AM, Diederick C. Niehorster wrote: >>> Hi John, >>> >>> Thats a quick dissection, thanks! I might not get to it in the next >>> week because of a move, but i hope i can figure this out further. >>> Should you find the time, feel free to make the changes you think are >>> best and commit them of course! >>> >>> Best and thanks a lot! >>> Dee >>> >>> On Sun, Jun 24, 2012 at 12:22 PM, John F. >>> Fay<joh...@cy...> wrote: >>> >>>> I think this is the offending code, from "freeglut_main.c" around line >>>> 1675 in the Windows event handler: >>>> >>>> WORKS: >>>> #if 0 >>>> case WM_SETFOCUS: >>>> /* printf("WM_SETFOCUS: %p\n", window ); */ >>>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>>> break; >>>> >>>> case WM_ACTIVATE: >>>> if (LOWORD(wParam) != WA_INACTIVE) >>>> { >>>> /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, >>>> window->State.Cursor ); */ >>>> fgSetCursor( window, window->State.Cursor ); >>>> } >>>> >>>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>>> break; >>>> #endif >>>> >>>> >>>> >>>> DOESN'T WORK: >>>> case WM_SETFOCUS: >>>> /* printf("WM_SETFOCUS: %p\n", window ); */ >>>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>>> INVOKE_WCB( *window, Entry, ( GLUT_ENTERED ) ); >>>> break; >>>> >>>> case WM_KILLFOCUS: >>>> /* printf("WM_KILLFOCUS: %p\n", window ); */ >>>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>>> INVOKE_WCB( *window, Entry, ( GLUT_LEFT ) ); >>>> >>>> if( window->IsMenu&& >>>> window->ActiveMenu&& window->ActiveMenu->IsActive ) >>>> fgUpdateMenuHighlight( window->ActiveMenu ); >>>> >>>> break; >>>> >>>> #if 0 >>>> case WM_ACTIVATE: >>>> if (LOWORD(wParam) != WA_INACTIVE) >>>> { >>>> /* printf("WM_ACTIVATE: fgSetCursor( %p, %d)\n", window, >>>> window->State.Cursor ); */ >>>> fgSetCursor( window, window->State.Cursor ); >>>> } >>>> >>>> lRet = DefWindowProc( hWnd, uMsg, wParam, lParam ); >>>> break; >>>> #endif >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 6/23/2012 11:15 PM, John F. Fay wrote: >>>> >>>>> OK ... >>>>> >>>>> SVN version 835 works properly but does not bring up full-screen >>>>> properly. >>>>> SVN version 836 does not work properly and does not bring up >>>>> full-screen properly. >>>>> >>>>> Let me look some more tomorrow. >>>>> >>>>> - John F. >>>>> >>>>> >>>>> On 6/23/2012 4:58 PM, John F. Fay wrote: >>>>> >>>>>> On Windows 7 with MSVC 6.0 I get the following behavior when I add >>>>>> the entry callback to the first window: >>>>>> >>>>>> Click in the first window: no menu. The entry function is called. >>>>>> Click in the second window: a menu appears. The entry function is >>>>>> not called. >>>>>> Click in the first window: the menu moves to the first window. I >>>>>> don't know if it's reopening the menu or just moving the already-open >>>>>> menu. The entry function is not called. >>>>>> Click in the first window again: no menu. The entry function is >>>>>> called. >>>>>> >>>>>> It's highly repeatable. >>>>>> >>>>>> - John F. >>>>>> >>>>>> >>>>>> On 6/21/2012 6:36 PM, John Tsiombikas wrote: >>>>>> >>>>>>> On Thu, Jun 21, 2012 at 12:31:43PM +0800, Diederick C. Niehorster >>>>>>> wrote: >>>>>>> >>>>>>>>> I've tried "one" and it doesn't work with freeglut-2.8.0 from Fedora. >>>>>>>>> After downgrading the dynamic library, the same binary works. >>>>>>>>> >>>>>>>> That is a very troubling report! Right now I am not sure what might >>>>>>>> have changed to the menu code between 2.6.0 and 2.8.0 (its a two year >>>>>>>> interval), nor am I familiar with the Linux side of things... >>>>>>>> >>>>>>>> John T, could you try the one demo and see if the menu's work (after >>>>>>>> pressing escape to leave game mode)? Then we'll know if this is >>>>>>>> reproducible. >>>>>>>> >>>>>>> Aha! evidently they don't! I even tried the single program I *ever* >>>>>>> wrote where I used glut menus, and it doesn't work there either. So >>>>>>> it's >>>>>>> not something wrong with the demo. >>>>>>> >>>>>>> That nobody noticed until now, says something about the >>>>>>> pointlessness of >>>>>>> glut menus I think :) >>>>>>> >>>>>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> Freeglut-developer mailing list >>>> Fre...@li... >>>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >>>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Freeglut-developer mailing list >>> Fre...@li... >>> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >>> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: <ipe...@it...> - 2012-07-14 22:19:27
|
Hi Jason, i did a little research about this setfocus and i ended up to the following: The Windows message handling procedure sends keyboard events only to main windows. If you want to send them to subwindows you have to deliberately set the focus to them with setfocus. GLUT (version 3.7.6) deals with it by finding which window is under the mouse and sends the keyboard event to it. I assume that this was dealt in FREEGLUT temporarily by this setfocus which later became permanent and nobody could remember who put it there in the first place. In one of my previous posts on this subject i posted some code which overcomes the problem by setting the focus only if this is the active window (foreground) already. Alternatively, we could send the keyboard strokes to the current window although this behaviour would be different than GLUT. Ioannis Quoting Jason Wilkins <jas...@gm...>: > Commenting out this SetFocus solved the problem of windows being > activated on mouse over. I'm not sure what the purpose of that code > was. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Jason W. <jas...@gm...> - 2012-07-15 01:19:07
|
How about using the SWP_NOACTIVATE flag? That would keep the window from becoming activated, since getting the focus and becoming active are actually different things. I had a patch which does this for menus, since menus should never become the active window. Freeglut is the only program I've ever used where the main window becomes inactive (grayed out) when manipulating a menu. I've still got to redo that patch and submit it. On Sat, Jul 14, 2012 at 5:19 PM, <ipe...@it...> wrote: > Hi Jason, > i did a little research about this setfocus and i ended up to the following: > The Windows message handling procedure sends keyboard events only to > main windows. If you want to send them to subwindows you have to > deliberately set the focus to them with setfocus. > GLUT (version 3.7.6) deals with it by finding which window is under > the mouse and sends the keyboard event to it. > I assume that this was dealt in FREEGLUT temporarily by this setfocus > which later became permanent and nobody could remember who put it > there in the first place. > In one of my previous posts on this subject i posted some code which > overcomes the problem by setting the focus only if this is the active > window (foreground) already. Alternatively, we could send the keyboard > strokes to the current window although this behaviour would be > different than GLUT. > Ioannis > > > Quoting Jason Wilkins <jas...@gm...>: > >> Commenting out this SetFocus solved the problem of windows being >> activated on mouse over. I'm not sure what the purpose of that code >> was. > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: <ipe...@it...> - 2012-07-17 05:33:19
|
Hi Jason, i'm sorry i don't get it. The SWP_NOACTIVATE is about SetWindowPos. I was refering to the SetFocus inside WM_MOUSEMOVE. Do you mean the way menu windows are handled? Ioannis Quoting Jason Wilkins <jas...@gm...>: > How about using the SWP_NOACTIVATE flag? > > That would keep the window from becoming activated, since getting the > focus and becoming active are actually different things. > > I had a patch which does this for menus, since menus should never > become the active window. Freeglut is the only program I've ever > used where the main window becomes inactive (grayed out) when > manipulating a menu. I've still got to redo that patch and submit it. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |