Blitz3d, Text Boxes, Slowdowns...

Archives Forums/Win32 Discussion/Blitz3d, Text Boxes, Slowdowns...

Picklesworth(Posted 2005) [#1]
This is my source code and executable.
http://crumbsoftware.f2o.org/files/NewGUI.zip

The Blitz runtime window slows down (or maybe causes severe interference with its parent window) whenever the user puts the mouse over a text box or combo box.
The exact place where the problem occurs is:
"apiInvalidateRect runtimewindow,0,True"

Does anyone know what's going wrong?

Also, the application keeps running as a process, even when the window is closed... Judging by my Notify thing at the end, it stays in the main loop without realizing that WindowMain no longer exists. The problem, strangely, only occurs when the combo box is present. If I remove it, the problem won't happen...


Perturbatio(Posted 2005) [#2]
runs fine for me, no slowdown and no process in the background after closing.


Picklesworth(Posted 2005) [#3]
What version of Windows do you have?


Sarge(Posted 2005) [#4]
Yup, runs fine for me too, my window's is Home Edition


Perturbatio(Posted 2005) [#5]
XPHome SP2


Picklesworth(Posted 2005) [#6]
I'm on XP Pro SP2...
Well, that's weird!


Allright, now that I'm running it directly as an exe without the ide, the slowdown doesn't occur... But the left-over process is still there.
Are you checking the Processes tab or the Applications tab on the task manager?


Edit: Alright, I've linked the text box slowdown to the process staying on after exiting with the "x" button... Even when the process is closed, there is still another thing running which causes this slowdown. Therefore, on first run it works fine, which is the reason why you didn't get any slowdown.

Thus, my problem has come down to this: Why isn't it exiting right?!

A strange thing there is, if I have a notify command called every single loop (thus knocking WindowMain into focus every single loop), the application exits perfectly fine when the "x" is clicked. So it must be something to do with window focus or the window heirarchy.

Another strange thing there is how when the window is closed after pressing X, and it is not visible (but, as I said, still there as a process), pressing any key will cause it to end properly.


Perturbatio(Posted 2005) [#7]
Are you checking the Processes tab or the Applications tab on the task manager?

The processes tab since that's where you look for running processes :)

it exits fine for me with the X and with File->Exit.
*EDIT*
ok, I have since restarted my computer and I ran it again and now I get a process remaining (there definitely wasn't one before, I looked several times).
When I closed it previously (several hours ago), I clicked the X and it showed the same message boxes that it shows when you choose exit. but it isn't doing it this time.


Picklesworth(Posted 2005) [#8]
It seems to be a sort of a random event to me as well.
I'm thinking that it freezes at the event handler, and so never reaches the check at the bottom of the loop.



Edit:
I should stop solving these myself. It feels undignified :D
Thanks a lot for the help. I wouldn't have figured this out otherwise. Actually, I still haven't figured it out :)
Anyway, through a long and horrible struggle through miles and miles of random typing, I managed to make it work, strangely by turning the blitz runtime window's style to WS_POPUP, hiding it to avoid artifacts, and then showing it again when all the sizing bother was dealt with...
I guess this was my first ever real bug :D (well, the MAVs just feel a bit too boring to be considered bugs)


Damien Sturdy(Posted 2005) [#9]
Hah. good good :)

a *real* bug is when it was all working really well, then you play with visuals, and the network code breaks in such a way the program hangs and needs a system restart despite never changing anything to do with networking. THAT's a bug :D