Moving window freezes program
BlitzMax Forums/BlitzMax Programming/Moving window freezes program
| ||
| I am creating a client-server game, and have noticed that when I grab the title bar of a BlitzMax program window, the program will freeze until I release it. This means that if someone drags the server window across the screen, it will stop responding to clients during the operation. How can I keep things flowing smoothly if someone wants to move a window? Thanks! |
| ||
| With EventHooks. I don't know much about them, but that's the term. If you search for that, I suspect you'll find what you need. |
| ||
| Hey I have the exact same problem :) Please let me know if you figure out how to fix it.. |
| ||
| Are you sure Gab? Surly if the program is suspending while waiting for the window to be placed, then all that would happen is that the queue would fill-up? Its only running one thread, and if that thread is handleing the screen, then the hooks wont override this would it? |
| ||
| Are you sure the program is freezing up, or is it just not redrawing while you are dragging? I will have to test this. |
| ||
| Just tested this, and you are right. It stops running completely. Now, I wonder if that is a symptom of all Windows' windows. |
| ||
| Well, surely it isn't -- I can drag my media player around without the music stopping! |
| ||
| I can drag my media player around without the music stopping Ahhh, but is your Media Player actualy playing the Music? Or has it just sarted a background task to play the music? |
| ||
| Try the RedrawGadget example for an example of hooks at work. Windows goes into an infinite loop while the mouse button is down for both window and scrollbar movement, fortunately it issues a callback so hooked messages can be serviced such as the 100hz watchdog timer that keeps the redrawgadget applet alive. |
| ||
| I've been testing it with eventhooks and it works perfectly. I had the problem that my canvas was not redrawed when the window was being moved. Using hooks fix it, so events are being processed when the window is being moved. If network events are't being processed, it seems like a BlitzMax bug to me. |
| ||
| seems no search in the forum was done: http://www.blitzmax.com/Community/posts.php?topic=66207 bye MB |
| ||
| That thread is about someone who insists on using a Max2D window and not a MaxGUI window, utter foolishness... |
| ||
| @watusimoto: Time to switch to Max Gui? |
| ||
| That thread is about someone who insists on using a Max2D window and not a MaxGUI window, utter foolishness... Skid, are you saying if you have a game that can run fullscreen or windowed then you should use 'Max2D' for fullscreen and MaxGUI for windowed? |
| ||
| How about taking the titlebar off the window so it doesn't exist. Then the user can't grab it and cause your app to quit responding. Then, just draw a titlebar at the top of the window yourself. And if the user grabs it, you move the window. |
| ||
| I am using Max2D. Would switching to a MaxGUI window fix my problem? Are there any drawbacks to using MaxGUI? Why doesn't everyone use it? |
| ||
| $30 |
| ||
| watusimoto, no after a little bit of testing I think you just need to get your head around hooks I've posted an example in tutorials of running multiple services from a hook. |
| ||
| I don't use MaxGUI for windowed mode. Guess I'm a fool. Any more elaboration please? |
| ||
| I dont either Grey. I think what skid was trying to say, was that if you didnt know how to do it in max2d, then you should really be using MaxGUI. (A little bit like when someone wants smoth scrolling, and the simplest answer is buy Greys Framework ;) |
| ||
| could be true. But it won't work on totally crappy PCs, NOTHING will...except locked into a fixed Hz gameplay which will fail in windowed mode (well, be too fast most likely). Anyway I saw a solution for redrawing the screen during windowed mode (non-GUI) kicking around here a while back, probably have it bookmarked somewhere... hmm I found this, may be useful but not to me: http://www.blitzbasic.com/Community/posts.php?topic=62786#701967 |
| ||
| An "if you don't know" sounds like an offense to all people willed to produce something without knowing every little detail of OS and pc-interna (ticks). They may just use the imagination in their heads and some nifty and small commands to give them a place on the harddisks of gamers. To the hint to remove the titlebar... as long as an application can be focused (or also focussed by clicking on the app-button in the taskbar) it can also be moved by shortcuts or even special keys on keyboards or mice. And for the solutions given up to now: if the pc cannot handle the things the application wants (too slow and too crappy graphiccards) the whole thing stops and even the mouse will not respond (some of my users claimed this problem to occour on their <1ghz pcs). But before I drift away from the topic: would be great if this moving-and-redraw-problem would be solved by BRL - just to make it default behaviour because there is -nearly- no reason to deactivate this for games or graphically intensive "applications". bye MB |
| ||
| @H&K, reading the post from Skid and I can't see how it means "If you don't know how to do it in Bmax, spend $30 on MaxGUI and learn how to do it in that as it's easier". So... Skid, what do you mean by... That thread is about someone who insists on using a Max2D window and not a MaxGUI window, utter foolishness... ? |
| ||
| ok |
| ||
| So is it absolutely confirmed that moving the main window can be detected, and a game can fully function while being window-dragged with Max GUI, i.e. flip and do game logic? If it is, I'm not so sure we'll see any kind of implementation of this feature in main blitzmax, as that's a pretty strong selling point. |
   |