Not in the case of MFC, when applied as the example since the traits are created from the view window handle (all the decorations have already been applied and have separate handles.)
The inconstant use of traits is that we see I believe is that within the GraphicsWindowWin32 class if _ownsWindow is not set then traits(x,y,width,height) are assumed to be window relative vs screen relative when _ownsWindow is set. (At least up until realizeImplementation() is called, in which case all the size an position setup is bypassed if _ownsWindow is not set) I think that has been the case for as long as the MFC capability but there are no comments in the code describing the use case. Once the window is drawn and Windows sends a WM_SIZE or WM_MOVE message it is processed by handleNativeWindowingEvent() which calls resized() and it sets the traits as if _ownsWindow is set even if it is not(which confuses things but it seems to work). Additionally if _ownsWindow is set then the window is created based on traits about 6 lines before the call to areWindowDimensionsChanged() in init() so resized() is never triggered in that case. Glen Johnson Phone: 321-696-3122 Email: [email protected] From: osg-submissions [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Monday, November 2, 2015 8:28 AM To: OpenSceneGraph Submissions <[email protected]> Subject: Re: [osg-submissions] OGS 3.4.0 - The view provided by OSG is incorrectly positioned within window that has been previously created in Windows outside of OSG Hi Glen, Could the inconsistency in sizing come from the window manager resizing the window automatically such as when adding window decoration, or resizing the window dimensions to fit within a screen? FYI, I have reviewed your change and it looks like it's a more reasonable workaround, but I still feel it's hiding problems from elsewhere. It should be possible to query the window dimension and position for them to be the same size as the Traits, if they aren't consistent them something is amiss or been adjusted something. Robert. Robert. On 30 October 2015 at 20:37, Glen A Johnson Jr. <[email protected]> wrote: Lincoln, Robert, In taking another look at look at the code especially in light of Roberts suggestion of possibly adding something to traits that would flag the issue and realized that it is already in place. Traits already has an optional WindowData structure pointer that contains the HWND Handle. The presence or not of the HWND handle result is set in the class variable _ownsWindow which can be used to prevent the added call to resized if _ownsWindow is not set. This will certainly give us a more absolute test than checking for x and y being equal to 0. I do think however that the fact that someone felt the need to add check if a window has been resized before it has been drawn may point to other issues in the code. I think the only thing that the areWindowDimensionsChanged call could be catching is some inconsistency in the window creation setup. I'll make the make the changes that I'm suggesting here on my system and send you the GraphicsWindow32.cpp file shortly however I don't think that this is the only fix that we will need in the library based on what Lincoln is describing. Certainly at this point it will be better to have a complete fix than a quick one. Glen Johnson Phone: 321-696-3122 Email: [email protected] <mailto:[email protected]> -----Original Message----- From: osg-submissions [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Lincoln Nxumalo Sent: Friday, October 30, 2015 3:30 AM To: [email protected] <mailto:[email protected]> Subject: Re: [osg-submissions] OGS 3.4.0 - The view provided by OSG is incorrectly positioned within window that has been previously created in Windows outside of OSG Hi Glen and Robert, I am also developing using MFC and as much as I would like a quick fix for this issue I'm afraid Robert could be right. The bug that we are seeing could be a symptom of of more serious problem. The reason I am saying this is because I tried building a GL3 context in MFC and I ran into another problem. The viewer is not responsive; the viewer fails to grab focus and the colors are not properly displayed. The only visible colors are blue and white and the loaded model is zoomed in a lot such that only a small portion of the loaded model is visible. And this is with or without the proposed fix. So clearly there's a more fundamental issue that needs to be resolved. The bugs that we are seeing are more likely a result of such problem. Currently I do not have a solution but I am working on it and hopefully I can have a permanent fix a.s.a.p. Hopefully other windows developers can pitch in as well and try to assist. ... Thank you! Cheers, Lincoln ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65493#65493 _______________________________________________ osg-submissions mailing list [email protected] <mailto:[email protected]> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph. <http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org> org _______________________________________________ osg-submissions mailing list [email protected] <mailto:[email protected]> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
