ENIGMA Forums
Outsourcing saves money => Issues Help Desk => Topic started by: time-killer-games on September 29, 2014, 12:41:50 am
-
No need for anyone to fix the bug instantaneously as it isn't urgent but I'd at least like to get an indication my bug report was noticed if that's isn't a big deal. And to know it is at least planned to be fixed some time within the near or distant future, as long as it happen sooner or later, thanks!
http://enigma-dev.org/tracker/index.php?id=838
-
I plan to fix it TKG, I seen it already too, I'm in hell right now trying to fix LGM's unsaved changes dialog so that it only shows when there were actually changes.
-
I plan to fix it TKG, I seen it already too, I'm in hell right now trying to fix LGM's unsaved changes dialog so that it only shows when there were actually changes.
Even GM cannot do this. But no harm in trying your best to make it better than it is at the moment.
-
TKG, I am sorry but I was unable to reproduce the unexpected results, everything works as intended. Perhaps do another git fetch and git pull because we were setting a default window flag before that caused this behavior and I have since removed it and you may not have the changes.
https://github.com/enigma-dev/enigma-dev/issues/838
-
I just updated the git master zip contents over-writing all conflict under /enigma-dev/ with no success. Same issues. Is there something I'm not doing right?
-
Possibly, there may have been conflicts, try getting the new Portable and other suggestions I have mentioned on Git.
https://github.com/enigma-dev/enigma-dev/issues/838#issuecomment-57354209
-
I) I can see the window changing size directly after I dragged the window. It isn't that hard to notice. :P
II) To verify what I saw, I measured the size difference as follows..
A) Ran the exe, when the "game" has opened completely (finished loading) and screenshot'd it.
B) Cropped out everything except the client area, pixel-exact, which measured 640x480.
C) Dragged the window, noticing the client height changed a little based on my vision.
D) Screenshot'd the window again.
E) Cropped out everything but the client area, pixel-exact, which measured 640x484.
F) With a tool window, the height is 4 pixels off.
G) The resulted resolution change is more or less wrong based on the window type my window styler extension has assigned the window.
III) Using the same exact project, GML, and DLL, GMStudio does not share this problem.
IV) I'm on Windows 7 x86 but I'm positive this isn't the isssue ;)
V) FYI in GMStudio window_get_width/height(), window_set_size(), and the last two args of window_set_rectangle() are based on the *client* width/height, not the border.
A) ENIGMA should do the same thing as explained in V) as it actually makes sense. Microsoft's MoveWindow idea was an epic fail. Plus it would fix GM/GMStudio incompatibilies.
B) window_get_x/y(), window_set_position() and (only) the first two arguments of window_set_rectangle() ARE based on the window border's position.
VI) That "new" portable hasn't been updated in five days, and I definately since then have downloaded and applied that update. :P
-
My mistake, I actually didn't test height only width, but I went back and downloaded your original and made no changes except drawing the dimensions to the screen, dragged it and still could no reproduce it, I also tried changing the various flags from GGS, and still nothing. I also opened Paint.NET and tested to make sure the window functions were reporting the correct dimensions, and they are, test the screen shot for yourself. I additionally ran the same test exactly as you described on the executable that you built, and still could not reproduce it.
(http://i.imgur.com/RS9jC6g.png)
V) FYI in GMStudio window_get_width/height(), window_set_size(), and the last two args of window_set_rectangle() are based on the *client* width/height, not the border.
A) ENIGMA should do the same thing as explained in V) as it actually makes sense. Microsoft's MoveWindow idea was an epic fail. Plus it would fix GM/GMStudio incompatibilies.
My apologies, I stated that backwards, we do actually do that.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Platforms/Win32/WINDOWSwindow.cpp#L160
-
Something weird just happened, again. I'm not experiencing what you are.
We should change ENIGMA to ENIGMARR like the nonsense subforum suggests: the Explosive, Non-Implosive Game Maker Ass-Rectum Ripper.
-
TKG, this is upsetting to me if this is related to your other issues because I thought I read you guys saying something about it not being consistent between even Windows versions? I honestly can't tell you man, if I can't replicate it I have no idea what the issue might be, I had some ideas but they all proved to be false. Do you have any ideas of what could be going wrong? You can see all of our window code and the flags we set, you might have a better insight into why your extension is bugging out than I do because I don't have your extensions source code and really don't understand it as well as you. I'm all ears man and willing to resolve this issue if we can figure it out.
-
The c++ code blocks project is in the zip under /datafiles/ subfolder. This really stinks you're very generous and want to help which I'm thankful for but I don't know what I can say or do. I'm super confused by the inconsistency we're seeing. :(
-
I see TKG, and I have looked at the source code now, and I want to say you may not have formatted it perfectly but your code was very legible and it was easy for me to read, nice work!
Now like I said above, I experienced what you are experiencing with WS_EX_APPWINDOW, do you remember about the GUI layer and scaling being slightly squeezed in the following picture? (look at the left; the black 5px gap)
(https://dl.dropboxusercontent.com/u/79893663/Problems/Problem%202.png)
Well it was the extended window flag that caused it, the only thing is that it was consistent for both of us. So I sort of want to point the finger at WS_EX_TOOLWINDOW since that is the style you set by default, but it doesn't have that affect for me. So possibly try commenting out just that flag, rebuilding your DLL and test again to see if it might be the cause. I am not saying it may directly be the cause but mixing that flag with some other flag that ENIGMA sets may be causing the issue for you.
Also just want to point out to you the file and line number where we set window flags in ENIGMA. You should also investigate this in your tests.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Platforms/Win32/WINDOWSwindow.cpp#L50
Also just for reference the following link is the Microsoft documentation on the Extended Window Styles.
http://msdn.microsoft.com/en-us/library/windows/desktop/ff700543%28v=vs.85%29.aspx
Primarily see if you can come up with a way of reproducing it on my machine, Windows 8.1
Also because you are embedding child controls, though not with this extension, it could also be related to the following issue.
http://www.gamedev.net/topic/397910-how-toolbar--menu--statusbar-change-the-client-area-win32/
The issue could also be the EXITSIZEMOVE message that the window reads.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Platforms/Win32/WINDOWScallback.cpp#L136
Perhaps try making windowWidth and windowHeight just the client area size, so GetWindowRect for x/y and GetClientRect for width/height, in that method instead of that other whacky jazz.
-
I'm in hell right now trying to fix LGM's unsaved changes dialog so that it only shows when there were actually changes.
Sorry, this is off-topic and I don't know if you got that to work yet and what I'm about to suggest is totally evil and not recommended and you should probably not do it and it's probably not gonna help but...
You know what you could do? When the user is about to quit, serialize the project object into a memory stream, then read the project file into another object and serialize it into another memory stream and... compare the streams. If they're different, show the dialog.
-
Would work if the games serialize fast. At the moment, a large game (like Iji) takes about ~15s to serialize... although it might be faster if you serialize it to /dev/shm or something like that.
-
The unconditional save dialog has been fixed in the newest release.
http://enigma-dev.org/forums/index.php?topic=2269.0