Assigning tabPanel.Value property disparate behavior

Targets
1

I’m working on a Mac/Windows cross-platform app for my work. The main window contains a tabPanel control. I have noticed that assigning the Value property of this control DOES fire the ‘Change’ event in Windows, but DOES NOT fire the ‘Change’ event in OS-X. Am I missing something here?

As a related question, is there a way to reliably trap the tabPanel ‘Change’ event such that a user can be prevented from moving to a different tab? For example, the following ‘tabPanel.Change’ event snippet runs perfectly well in OS-X, but fails by recursive stack overflow in Windows. In this snippet, the [Accept] Bevel Button being Enabled indicates that user edits remain uncommitted, and the user must either accept or apply their edits:

If (BBApply.Enabled) Then Me.Value = userTabValue '<--- This works in OS-X, but stack overflows in Windows Message( &cFF0000, "You must first either Cancel or Apply the changes made in this panel!" ) Beep Return End If

2

I think what you need to do is disable the TabPanel when you change the value back to the original. This will prevent the stack overflow. Assuming this is in the TabPanel.Change event:

[code]if me.enabled = false then return

If (BBApply.Enabled) Then
me.enabled = false //Keep the change event from overflowing
Me.Value = userTabValue
me.enabled = true //Put it back to normal
Message( &cFF0000, “You must first either Cancel or Apply the changes made in this panel!” )
Beep
Return
End If

[/code]

The ultimate problem is that the change event occurs, you try to set it back, which fires the change event, it tries to set it back, which fires the change event. etc. You get the point.

Is it a bug that it works on Mac OS X but not Windows? It probably has something to do with the platform not Xojo. Regardless, it’s easy to workaround.

3

Bob, thanks for the help. That work-around seems reasonable.

4

<https://xojo.com/issue/54708>