Home | Reviews | GUIpedia | Forum | Fun500
| MPNQB | Windowing systemEverytime I attempted to build a window system, it ended in disaster. My last attempt was a window system containing controls, however the controls would inexplicably move to the next window after you closed one window's controls. I never figured this out and scrapped the system I wrote altogether.
When I create a window system with objects, I typically create a couple arrays, like Windows(NumWindows). The system checks Windows.Active(NumWindows) to see if the window is used, then it checks .X, .Y, .Titlebartext, etc. and draws it. But inevitably I'd end up getting it all mixed up, like Windows(1) would end up correpoinding to whatever the first window in the Z-order was, etc. Then once I got that resolved, they wouldn't close, etc. Then I'd add in controls using a similar convention and then the kernel goes down in spectacular flames. Don't ask me how, but I've even bluescreened the computer trying to make a window sysyem in Freebasic, under DOS, in Virtual PC. Yes, the host actually BSoD'd.
There has to be a better way to do this. Anybody have some tips to offer or code to look at? If you've designed a good window system, tell me how you did it. | 2009-01-08 | 9:33 PM |
| Brandon | Re:Windowing systemWindowing systems can be hard. The best way, I find, is to work like hell, and then if you have a problem, walk away come back, and if it still doesn't work, scrap the bad part and try from a different angle. It would be ideal to post the code on a forum and have one of us look at it, but it always seems when I'm having trouble, everyone is busy. | 2009-01-08 | 9:56 PM |
| aguma | Re:Windowing systemwell i thought of an idea that might make things slow but maybe easier to program, but anyway since a single-tasking windowing engine is so much easier, just copy all the data into the main arrays and pretend that's your program for like 0.1 sec, then switch programs. I don't know if that'll be easier or anything, just a thought... | 2009-01-09 | 12:10 AM |
| Re:Windowing systemI've never made a windowing system with FB, but with Ikon what I did was this.
A window is created, then saved to a memory bitmap so it doesn't have to be redrawn, just blitted back to screen during a refresh. A winid (window id) is returned from the createwindow function. Each control that is added to the window is a struct with a variable called [b]winid[/b]. winid refers to the parent window of that control. If the window is closed, any control that has a winid of the closed window is destroyed. Since each control can only be associated with one particular window, it can NEVER be viewed on another window.
So for a button, you would have a struct such as:
(this is in pseudo code)
type BUTTON
winid as integer 'which window?
used as integer 'is this button valid or free for allocation
x as integer 'position within that window
y as integer 'same as above
caption as string 'the button's text
end type
When it comes to the Z order of windows, I never did get that quite right. My main problem was that I never thought about it until I had done a lot of other work on the system already, so now it's really just a hack.
A window struct could be something like this:
type window
used as integer 'am I in use?
z as integer ' my z-order position
x as integer ' screen position
y as integer ' screen position
w as integer 'width
h as integer ' height
caption as string ' window caption
end type
So what happens is this, if there are three windows and a user clicks the 2nd one, ALL of the other windows are demoted by one, and the clicked window is promoted to spot number one. So as you can see, after a while, if a window hasn't been clicked, it could end up at say, position number 100, even if there are only a few windows open.
I did manage to do another hack around that problem though, if a window gets too far down the list, it gets promoted to the highest position available, right below the currently visible window. I'm sure anyone can come up with a better way of doing that, but as I said, I didn't plan for it early on.
I hope this helps a little. I could go into more detail but then it would be better to write a whole tutorial. And I'm sure my way isn't the best. Good luck. | 2009-01-11 | 2:04 AM |
| Brandon | Re:Windowing systemFor my Z order, I cheated, all I did was the last window to be clicked became the value of ACTIVEWINDOW. Then in the For...Next loop where the windows are drawn, if the window is the activewindow it isn't drawn. Then after the next, it is drawn last.
I used memory bitmaps in Fun500 2 through 4 as they really are the best way, in an engine with movable windows. | 2009-01-11 | 8:46 AM |
| Re:Windowing systemInitially I did what you did Brandon. It's simple and it works. But later on I needed the windows below it to appear in the order they were last used. Otherwise they would just be refreshed according to their position within the window array, with the current window on top. That is fine, except when a user is trying to get information off of a window, say 3 levels down, and typing it into the currently active window.
Another way around this problem without worrying about z-order, is to have the last used window drawn just below the current window. So you could have two variables, activewindow, and lastusedwindow. Then a user could be reading a programming tutorial, and typing in the text editor. | 2009-01-11 | 1:44 PM |
| Brandon | Re:Windowing systemYeah, As I was typing that, I realized how much I really should have at least the last 2 drawn right. | 2009-01-11 | 2:04 PM |
GUIs
2021 Brandon Cornell
