exxos blog - random goings on

[exxos]

I think I figured it out. The problem does not happen in XaAES, only in TOS. I assume in TOS when the window is moved it means the entire window to its outer edges. I was clearing that area which was why the window was vanishing. But only when it was being moved off screen.

In XaAES the problem did not happen anyway.

[exxos]

I'm not sure WF_WORKXYWH Is even getting the correct sizes..

As if it grabs the working area, and I start my text at x+2,y+2, This should be two pixels within the working area ?!

Code: Select all

junk=wind_get(our_aeshandle2,WF_WORKXYWH,x,y,w,h) ' get work area of the main window (internal)
vs_clip 1,x,y,w+x,h+y
v_gtext x+2,y+2+(j*char_hi),INFO_DATA$(j) 

However.

Capture.PNG (77.8 KiB) Viewed 1721 times

So I can only assume I am supposed to add on the menuy size as well

[HigashiJun]

Will never forget this superb cosplay from Dragon Con a few years back...

[exxos]

menuy does not seem to be want to use.

a.PNG (23.3 KiB) Viewed 1712 times

So adding a single +char_hi give this now.

b.PNG (20.92 KiB) Viewed 1712 times

There is a 2px offset on the X.


Not sure why the window vertical character scaling isn't working properly though

Capture.PNG (77.05 KiB) Viewed 1709 times

[exxos]

Found another odd new problem

Because the new info window is open, clicking on the main GB7 window on tests does not do anything. As expected really. BUT, if I move the info window over the top of the main GB7 window, I can actually click tests and they run

Capture.PNG (148.43 KiB) Viewed 1706 times

I think the universe is telling me I should quit programming and just not bother

[exxos]

I seem to have developed a new problem which makes no sense either

When passing 3 for the button event..

Code: Select all

ev_bmask	A bit-vector, which masks the buttons to wait for with a 1. The following apply:
Bit-0	=	Left button
Bit-1	=	Right button.
Bit-2	=	Middle button, PC-GEM

The problem is it only ever registers the right mouse button.

Basically :

Code: Select all

if e = MU_BUTTON AND button = 1  AND mess(3)=our_aeshandle then 

Does not work.

However it all works perfectly fine on the right mouse button.

Code: Select all

if e = MU_BUTTON AND button = 2  AND mess(3)=our_aeshandle then 

The current event line I'm using...

Code: Select all

       e=evnt_multi(mu_mesag+MU_BUTTON+MU_KEYBD,258,3,0,0,0,0,0,0,0,0,0,0,0,_
                       VARPTR(mess(0)),0,xa,ya,buttona,kstate,kr,br) 

I even dumped the events to a file and it absolutely never ever registers a left button click. It does however register a message event on the window, but not a button click event.


Even more odd is that the AES_handle is not returned (comes back as zero) when my info window is not open. However when the info window is open, the handle is correctly returned, however they never registers a left mouse button event. But it does on a right mouse button event.

My debug.

Code: Select all

'e,          buttona,      handle,      our_aeshandle

'info closed, gem window open
' 2             1             0             3 'left button does not return AES handle now ?!
' 2             2             0             3 ' right button does not return AES handle now ?!

'info open, gem window open
' 16            0             3             3 - left click nope - Correct AES handle
' 2             2             3             3 - right click yes - - Correct AES handle

[exxos]

I did a sanity check both windows were actually opening with a different handle. In the main window is handle3, and the info window is handle5.

So how come regardless of which window I actually click on, the AES returns window 3 ?!

Even more crazy is when the two windows overlap it returns a keyboard event and not even a button event.

Clicking the info window over the desktop and it returns a button click. But again it is the wrong handle anyway.

I think it is pretty much going to be impossible to resolve this. Because I am running Hatari,EMUTOS,TERADESK,FREEMINT, XaAES, HISOFT BASIC, and my own code. in all likelihood it is probably my own code but with all these problems of "software running inside of software" multiple layers it is practically impossible to diagnose exactly where the problem is

[exxos]

Trying to install MiNT. The hard drive installer would not install from hard drive. I created myself a blank floppy to copy it in Hatari to copy the files from C: to A: and...

Seriously ?!

Capture.PNG (48.12 KiB) Viewed 1639 times

[exxos]

So created a blank floppy in STEEM. Copied MiNT to that. Then loaded it into Hatari and installed.

Capture.PNG (84.52 KiB) Viewed 1635 times

So now the correct AES handles are reported!!

However oddly the left click is still reporting as a keyboard event.

Code: Select all

'MULTITOS - 
e,          buttona,      handle,     ,  our_aeshandle, our_aeshandle2
' 2             1             4             3             4 		' left info window click AES 4 - correct BUTTON
' 1             0             3             3             4		 ' left GB6 main AES 3 - correct - KEYBOARD EVENT AGAIN ?!

our_aeshandle = Main GB7 window (3)
our_aeshandle2 = INFO window (4)
handle = what the AES returns.
e= EVENT. 2= MOUSE BUTTON, 1= KEYBOARD.

So something is royally fu**ked up in that FREEMINT / XaAES setup of yours @Badwolf .Something in that setup is not reporting the correct AES handles. But it works perfectly well in good'ol MinT.

So if I continue with MiNT (EMUTOS) . The problem I actually have is why one of the mouse buttons is returning as a keyboard event only.

[exxos]

@Badwolf Could you put evnt_multi in your 2 windows test program and just get it to output what window is clicked on ?

Code: Select all

       e=evnt_multi(mu_mesag+MU_BUTTON+MU_KEYBD,258,3,0,0,0,0,0,0,0,0,0,0,0,_
                       VARPTR(mess(0)),0,xa,ya,buttona,0,0,0) 

MU_BUTTON incorrectly returns "16" for left button clicks. I can't believe the AES is that badly messed up. TOS is doing the same. So its looking like the function is broken in hisoft. If it is, there is really no point in continuing with it all. The only work around would be to call it from assembly and pass the values back to GB7. But I need to prove the function is broken first