exxos's Atari, Amiga & retro forum

I will probably jinx it but I think I might have stumbled on the menu problem..

It was looking for a event message then looking for the menu item clicked on... However there was no check for checking if the menu was actually selected which I was puzzling over previously.

So now mess(0) = MN_SELECTED is added and after 30 window moves its not gone nuts.
I think what was happening was any message redraw event which happened to hit the variable of a menu item such as 1,2,3,4 or whatever, would trigger the menu even though nothing in the menu was selected.

I think this is why it was so random and could happen anything between 2 or 30 window moves. The window would have to be located at particular points on the screen to hit the variable numbers to trigger the menu system..

D'oh!

Back to the weird graphics redraw problems then...

Read this.. so yeah.. it sets the squares.. and I can clear them.. But WTF redraws the squares ?! It's like the AES magically knows what it's doing, but then why would it send the sections to redraw to the application and then expect that to do it.. when there is nothing to redraw the squares in any texts or examples I have seen so far. I don't get it :(

Half the time the desktop windows don't redraw. It did earlier, so no idea what I changed there now :roll:

Something is definitely FUBAR.

If I open GB7 first then the C: drive, and move the GB7 window, I get this..


BUT.

If I open the C: drive window FIRST, then open GB7 and move it.. both Windows refresh correctly when moving about.


There must be something screwy with the window handles somewhere :roll:

EDIT:

FFS! Yep the bloody handle changes. You would think when you open up a window that the handle would remain the same. But nope it could not be that simple could it!

My window handle is 3 when I launch GB7. then when I open C: drive window, my GB7 and then becomes 4!

It would have made more sense it being 4 if the C: drive was open first, then GB7 opened as it would be the next window which had physically been opened. But nope :pullhair: :cussing: :cussing:

After messing around it seems the WM_TOP window is the window which is selected from the DESK menu.

This makes things rather problematic because Background windows can be dragged about without them actually being "on top". however this cannot be for the GB7 window.. because what do check ? I have to check if the messages are for that window or not.. So it is basically not movable unless it is selected as the "on top" window. It seems a bit of a catch 22 problem.

There must be some other way of getting the actual AES handle of a window as the window ontop could be anything. Then the handle changes, so I cannot issue redraw events. Damned if you do and damned if you don't :roll:

EDIT:

I think I am going to ignore WF_TOP as I don't get why it changes numbers which don't match the window ID's :roll:

Anyway, I am back to the redraw problem. As if I move the C: drive window on top of them move it away, the area is correctly cleaned but I still don't understand what is supposed to redraw that area afterwards ?!

If I manually redraw the area in the above example then incorrectly updates. BUT, when I move the GB7 window over the C: drive window, its back to screwing up that up again :roll:


There is just no way to bloody win :(

I don't bloody believe it, I don't know what I just changed ?! and now it's all working perfectly ??????




:dizzy:

The joy of programming...

:D

Gotta love it... :)