Writing a GUI system

superadnim · Post by **superadnim** » Wed Aug 13, 2008 6:42 am

I never got it to crash, perhaps you should try to run a memory diagnostic tool or run the code on another system, to rule that possibility out. It's the only thing I can think of, because I couldn't get it to crash.

But just in case, you should never manipulate a linkedlist unless you're sure it has a current element, etc.

Fluid Byte · Post by **Fluid Byte** » Wed Aug 13, 2008 8:33 am

I will take look after lunchtime ...

untune · Post by **untune** » Wed Aug 13, 2008 3:09 pm

superadnim wrote:I never got it to crash, perhaps you should try to run a memory diagnostic tool or run the code on another system, to rule that possibility out. It's the only thing I can think of, because I couldn't get it to crash.

But just in case, you should never manipulate a linkedlist unless you're sure it has a current element, etc.

Ran FB's code on my laptop, couldn't replicate the crash but I only ran it once, and it was running slowly (average 12fps) and I didn't have the patience to keep trying it

My code still crashed however... I've tried allsorts to fix it today but nothing seems to work. It's really starting to annoy me now because I can't add anything til this is out of the way

#NULL · Post by **#NULL** » Wed Aug 13, 2008 9:31 pm

i followed that interesting thread. i wrote something like that once, if you're interested: http://www.purebasic.fr/english/viewtopic.php?t=31357

nice stuff Fluid Byte

, looks pretty cool.

untune · Post by **untune** » Wed Aug 13, 2008 10:44 pm

#NULL wrote:i followed that interesting thread. i wrote something like that once, if you're interested: http://www.purebasic.fr/english/viewtopic.php?t=31357

nice stuff Fluid Byte , looks pretty cool.

Thanks for that #NULL, your code is really extensive... might take me a while to understand how it works

Still no luck with the memory problems in mine

untune · Post by **untune** » Thu Aug 14, 2008 2:06 pm

FIXED

Well, at least that's how it SEEMS for now

I was looking in the wrong place completely. I'm not going to rule out any possible bugs with the memory allocation just yet as I did get crashes with FB's code originally - whether my comp was just having a funny turn I don't know, but I've ran it since and it seems stable.

The problem that was screwing my strings up I have traced back to a single line, in a place I never thought to check (always the case isn't it?)

I have a CompilerIf that checks a constant called #GUI_SYSTEM_DEBUG, in the render procedure. Within this block is a chunk of code that just writes all the info that might be of use to the screen - ie all the structure info for the current panel, mouse coordinates, clicked buttons, FPS, list index etc etc.

Since I ran out of ideas I just tried running without the debug output to see if that affected anything. All of a sudden, I can't recreate the dodgy string problem (I had managed to figure out a series of clicks that would cause it to screw up, it'd happened that many times

) anymore

So I guessed it was down to my GetInfo function, which is called like this: GUI_PANEL_GetInfo(GUI_PANEL_MouseOver()). The mouseover procedure runs through the linked list from last element (topmost panel) to first (bottom) and checks if the mouse is in the current panel's rect - if it is, it returns the handle/LL element, otherwise it returns zero.

GetInfo was checking if the handle passed to it was <> #NULL. If it was, it simply created a string with no info taken from a structure, so on the screen it would display H_PANEL:, Sprite:, X pos:, Y pos: etc etc but no info next to them. Each of these "headers" is \n terminated so the whole string is listed down the side of the screen. If the passed parameter was nonzero, it then looped through the list AGAIN looking for the handle provided until found, then filled a string with all the info required. I thought it wasn't a good idea to be looping through the list so often... and I thought it was overkill to be looping in the GetInfo procedure. I changed the code so that if the parameter passed was nonzero, it would ChangeCurrentElement() to the one that was passed. Again it would fill the string with info.

I ran the code again but the problem was still there... so I commented out the code that fills the string with info and bingo... problem solved. So the string error for some reason was caused by this line:

Code: Select all

GUI_PANEL_INFO = "H_Panel: " + Str(GUI_LIST_PANEL()\H_Panel) + "\nSprite: " + Str(GUI_LIST_PANEL()\Sprite[#GUI_PANEL_SPRITE_AREA]) + "\nHeader: " + GUI_LIST_PANEL()\Header + "\nPanel top left X: " + Str(GUI_LIST_PANEL()\PanelRECT\X1) + "\nPanel top left Y: " + Str(GUI_LIST_PANEL()\PanelRECT\Y1) + "\nPanel bottom right X: " + Str(GUI_LIST_PANEL()\PanelRECT\X2) + "\nPanel bottom right Y: " + Str(GUI_LIST_PANEL()\PanelRECT\Y2)+ "\nArea top left X: " + Str(GUI_LIST_PANEL()\AreaRECT\X1) + "\nArea top left Y: " + Str(GUI_LIST_PANEL()\AreaRECT\Y1) + "\nArea bottom right X: " + Str(GUI_LIST_PANEL()\AreaRECT\X2) + "\nArea bottom right Y: " + Str(GUI_LIST_PANEL()\AreaRECT\Y2) + "\nSize X: " + Str(GUI_LIST_PANEL()\Width) + "\nSize Y: " + Str(GUI_LIST_PANEL()\Height) + "\nColour: " + Str(GUI_LIST_PANEL()\Colour) + "\nActive: " + Str(GUI_LIST_PANEL()\Active) + "\nDragging: " + Str(GUI_LIST_PANEL()\Dragging)

I need to figure a way around this because the GetInfo function is quite important for retrieving information from a structure... I'm also hoping that there is nothing wrong with the mouseover proc either.... but ah well, I'll worry about those when they go wrong

Fluid Byte · Post by **Fluid Byte** » Thu Aug 14, 2008 2:37 pm

Sorry I couldn't help you in the meantime but the code just got too big to fix the problem in a hurry. Although I never got so many errors like you got before you fixed it there are still some things to iron out. Anyway, I'm glad I could help and you got where you are with your GUI now. I will fix the remaining bugs in my code, think about how to properly integrate the gadgets and may release that someday.

untune · Post by **untune** » Thu Aug 14, 2008 2:59 pm

Fluid Byte wrote:Sorry I couldn't help you in the meantime but the code just got too big to fix the problem in a hurry. Although I never got so many errors like you got before you fixed it there are still some things to iron out. Anyway, I'm glad I could help and you got where you are with your GUI now. I will fix the remaining bugs in my code, think about how to properly integrate the gadgets and may release that someday.

No problem at all, I'm really grateful for all the help! Hehe it surprises me that there's still so little actually implemented in mine, yet it's already passed 1000 lines... biggest project of mine yet

I intend to keep this thread updated with progress though as things develop, and it'd be great if you did the same... any bugs you find might help me track down any in mine and vice versa

Keep up the good work

untune · Post by **untune** » Sun Aug 17, 2008 7:32 pm

Haha, I went and broke it again

I got mine looking nicer with textures, custom mouse pointer etc... but now I added a little feature to delete a panel when the middle mouse button is clicked and now I get my lovely screwed up strings again... eeeeh I'm beginning to wonder why I started this

Fluid Byte · Post by **Fluid Byte** » Mon Aug 18, 2008 1:02 pm

It's actually pretty weird, I can't get it to crash anymore! I know you had trouble with the DeleteElement() line, I got that error too. But no matter what I do know it doesn't crash. I am trying since half an hour but it's "just working" LOL.

superadnim · Post by **superadnim** » Mon Aug 18, 2008 9:45 pm

May I suggest a test-bed sort of system?, all the big companies do it and anyone can do it as well. I can't remember the exact name of this but you pretty much create test cases and perform N runs for each, you do know the outcome of each so you can also check not only the stability but the integrity of the code as you update it.

so, you can run window creation, deletion in one test - another test can do window movement, zorder, whatever - you run each test (while waiting for them to finish) on a thread, so if something crashes you can catch-error and continue execution at the same time you'd be able to pause the tests if required, etc.... microsoft actually puts their entire array of servers to perform this sort of tests before releasing any component. they simulate user input, tons of test cases, etc. best way to deal with stability issues.

I'm sorry I can't remember the word.... dyslexia isn't at all helpful

Oh by the way! no need to call ClearScreen() since you're drawing the scrolling background, you can save some FPS with that

The bg kind of reminds me of a similar GUI system but for blitzbasic