Something has a changed which makes Treeview and TreeviewPlus fail

[RacingDog]

I'm afraid that I don't know which version of Windows Mobile introduced this as I haven't used every version. Memory, which may be faulty after all the intervening years, says that 6.0 and probably 6.1 were OK. However, I was revisiting some old software on my current WM 6.5 Professional the other day and found that Checkboxes in either of the above controls no longer work. If you click on an embedded checkbox, the tick sign appears but then immediately disappears!

Here is a test program (and an attached version to save you doing the set up! You'll have to rename it to a .spb file though because the uploader won't accept that extension, which seems rather odd given the nature of this part of the forum)

Sub App_Start
tv.New1("form1",0,0,100,100)
tv.CheckBoxes=True
node1.New1
node1.value=tv.AddNewNode("red")
Form1.Show
End Sub

Needless to say this works fine on a PC, but not on a device. In case it's relevant, I'm using an HTC HD2.

This is a real killer because every WM app ever written using these controls which also uses Checkboxes is now useless, unless you have a seriously old device.

I understand that it is far too late to have anything done about this, but I thought people should know, just in case I'm not the only person on the planet still using WM 6.5.

Cheers all

 

[agraham]

This seems to be a known problem without a real solution - but see the last post

https://social.msdn.microsoft.com/F...s-on-windows-mobile-65?forum=windowsmobiledev

The reason appears to be this

It appears that the behavior we are seeing occurs because the Click event is being fired both from the MouseDown and the MouseUp events (instead of just the mouse up as it would in Windows or previous versions).
To show this, you can start by tapping on the checkbox, leaving your finger on the screen and dragging off the check box. It will become checked from the MouseDown event and will stay checked because the MouseUp event is not fired when you lift your finger from a different position. The same works for tapping off the checkbox and dragging on.

from here

https://stackoverflow.com/questions...eview-in-compact-framework-3-5-running-on-win

 

[RacingDog]

Yeah that makes sense, thanks AG.

Is there any organisation on the planet less aware of the saying "if it ain't broke, don't fix it" than Microsoft?
Is there any organisation on the planet that so totally fails to check it's software than Microsoft?

Sigh!

OK. I'm going to have a day or two of apathy, but after that, maybe I'll try something else, like getting rid of the checkboxes and using node selection to toggle BackColor instead. Oh dear, that'll be boring cutting and pasting then! Apathy, apathy!

 

[RacingDog]

Well that was amusing! I thought I'd dig out good old MyMobiler to do a spot of remote debugging. My first attempt was not a genuine test, just put in some code as starters but double check it before going further. That was .....

Sub tv_Aftercheck
If node1.Checked Then
Msgbox ( "Checked" )
Else
Msgbox ( "clear" )
End If
End Sub

Which makes everything work! It's totally useless as a solution of course, because constant Msgbox pop ups would be too irritating. As the tick appears before the box I guess it means the stray "mouse up" is still pending at that point and then being absorbed by using the box. As y'all may remember, Delphi on PCs is my main interest so there is lot's about this environment I don't know about, none the less, I can't help feeling this is suggesting a solution, but that's beyond me. Don't anybody waste time on this, but if the thought rattles around the old subconscious and pops out an idea, please do share!

There's something else I want to try though.

 

[RacingDog]

Well, well, well! Who would have thought it? The answer is actually quite simple once you have AG's information about Mouse Up and Down both being used.....

Sub tv_Aftercheck
If node1.Checked Then
node1.checked = false
Else
node1.checked = true
End If
End Sub

As noted previously, the mouse up still has to handled when this event is raised. So we simply undo the change that the mouse down made. It looks like it should cause a recursion, but it doesn't, so presumably the control is clever enough not to reraise the event.

Yay! I hope there is somebody else cheered by this news. If any of you are members of other forums where this has been discussed, please pass it on.