Odd behavior with SRP Buttons in new Controls.ocx (continued)

Opto_Will

I have branched this off as a placeholder for the continuation of my comments in this thread:
Number Formatting

Where I left my notes there, my examples decided to just start working consistently.

I now have a user just starting to use the system with the latest Controls and they have demonstrated to me 2 other instances where clicking on an SRP button either does nothing or exhibits some weird behavior like going to a field on an entirely different Tab.

I immediatley reverted the Controls and all was right again.

I will take a copy of that system offline and re-update the controls and see if I cant give an example this time.

KevinFournier

One thing to investigate, if you haven't already, is how you are qualifying events.

Opto_Will

So before I lose my mind chasing ghosts again I thought I would attach a quick Vid just so everyone can see what I am trying to describe.

3 Runs in this video, each immediately after the other.
1. Controls 4.1.21.1. Log into App. Show SRP button working as expected.
2. Change Controls to 4.2.1.1 & Re-register. Log into App. Show button NOT working as expected
3. Change Controls back to 4.1.21.1 & Re-register. Log into App. Show button working as expected again.

https://www.dropbox.com/s/rvr86njjnhe9a80/SRPButton new Controls issue.mkv?dl=0

Opto_Will

@KevinFournier

Well there were no Qualifying events initially so I added some.

It didnt matter if I tried
Send_Message(@WINDOW:'.OLE_DESPATCH','QUALIFY_EVENT','Ole.OnClick',0)
or
Send_Message(@WINDOW:'.OLE_DESPATCH','QUALIFY_EVENT','Ole.OnClick',1)

Didnt make a difference..

KevinFournier

Good news. I have an old copy of Opto and was able to recreate this using your video. Lemme investigate and get back to you.

Opto_Will

Not going crazy (Just yet!!!)

KevinFournier

Yes, that's the good news. The bad news is that the behavior is pretty weird, so it'll be a bit of work to track the issue down. If you notice, when you click on the button, it actually jumps back to the first page. This happens the moment the button goes down, but button click events actually fire when you release the button. I gotta figure out what is making the form change pages because the button isn't doing it explicitely.

Opto_Will

KevinFournier

Fixed in 4.2.1.2.

Opto_Will

@KevinFournier,

That is looking much better!

Care to share?

KevinFournier

Something was causing the button to get focus, and when that happens, since it's a toolbar button, it tries to pass focus onto the next control. The next control on your form that can actually get focus is a radio control on the first page. This is why I couldn't recreate on my end.

The hard thing about windows programming is that everything happens in messages, so if one message does something irresponsible, it might not be an issue until it manifests in another message down the road. This was the case here. The catalyst was a bug in identifying the correct MDI child window during the WM_MOUSEACTIVATE message. Under normal circumstances I would make sure to return MA_NOACTIVATE on this message for toolbar buttons, but the above mistake was causing me to let windows do default behavior... which is to attempt to give the control focus.

The bug was introduced while adding code to support OI 10 which has a slightly different window structure. As such, I have to conditionally compile to do one thing when compiling for OI 9 and a different thing when compiled for OI 10. I've had to add such conditions in a lot of places, and when I did so in this case, I made an error that was returning the wrong window handle. Everything else cascaded from there.

Incidentally, I suspect this bug caused the issue reported in Ed's discussion thread as well.

Opto_Will

Well I appreciate the effort in tracking down and correcting :)

To appropriate a little sumpin from AusMarkB....