Good Day -

I have a complex tabx used in our scheduler. In some RARE cases, the panel that "appears" to have focus is not the same as the "actual" panel that the program thinks has focus. This can happen when there are slow communications or user is rapid clicking... What can happen is that it appears that the user us making an appointment for Provider1 because it looks like it has focus but internally the progam is focus is on Provider2.

So my question is - is there a way to Query the tabx control and get panelID that has screen focus? I can compare that against the program focus to make sure its the same and if not ask the user to re-select the panel.

TIA

Ok, so if I understand correctly, the scenario is that due to network slowness or rapid clicking, the program sends a CTLOP_PANE to switch to Provider 2, but the command fails to get registered by the control and it somehow ends up on the Provider 1 tab. The program then loads the Provider 2 schedule into a grid on the panel, but the user thinks it's Provider 1's schedule. If that's an accurate description, then to avoid it you'd have to query the panel after issuing the CTLOP_PANE command and before populating the new panel. If you waited until the user had finished updating the grid, it would be too late.

If that sounds like what you're hoping for, then perhaps the simplest path would be to modify the behavior of the CTLOP_QUERY operation for TABX controls so that it returned the tab # in the cstatus parameter (instead of just > 0 to indicate the control was found). That would presumably have no adverse effect on existing apps, and also not require a new opcode.

Yes, that is an accurate representation but in reverse - they issue a click command for provider 1 and it looks like that is also represented on the panel (has focus) on the screen BUT the program fails to register the click event and stays on Provider 2.... so yes, being able to query that and double check the results vs the on-screen display would help prevent this. Tx.

I went ahead and made that change, as I could not see any downside. You can access it for testing via the following:

ash-7.0.1751.7-w32-upd.zip
ash70notes.txt

Goodmorning - thanks Cap.

Just fyi I wont be able to test this until next week. I read the release notes (I know, shocking!). In this case the panel # from left to right may not be helpful since the user can re-arrange the order of the panels at will. Is there any way you can return the actual Panel ID? This would provide better information to the program. TIA.

Well, we can't return that in the cstatus (numeric) parameter. But perhaps we could return it in the ctext parameter. Normally that would return the original ctext for the control, but in the case of a TABX, that probably wouldn't be of much use to anyone. I'll take another look...

Thanks - what is the purpose of the PanelID then? Does it return another way?

The paneid param in the CTLOP_PANE operation does support the option of using the text of the tab panel, but the cstatus return parameter is purely numeric, making it unsuitable for returning text. While I suppose it could be upgraded to allow either text or a number, I think the ripple effects would be much greater. Seems more straightforward in this case to adjust the value of the returned ctext parameter on a CTLOP_INFO call, in the case of TABX, to be just the current tab pane text rather than the entire TABX definition string. Or, if that seems to be giving up something of value, another option would be to create yet another opcode, CTLOP_QRYPANE which was exactly the same as CTLOP_INFO but returned just the tab panel text in the ctext parameter. That, however, would seem much more like a new feature, which for obvious reasons we would like to discourage in the middle of stabilizing 7.0.

Im not sure why you would want the "entire tabx definition string"...

I can't think of any reason either. It's just what the CTLOP_INFO operation normally returns, i.e. the same string that you used to create the control in the first place. But in the TABX case, that doesn't seem useful, so I've gone ahead and adjusted the CTLOP_INFO for TABX to return the current panel label instead. Here's an example of the code in the TSTTABX sample program:

The trace message I get when switching from the panel 1 to 2 (which are also labeled "One" and "Two") ...

Note that if there was an "&" in the label (to define an accelerator key), it will appear in the returned text. That may or may not be confusing, depending on how you define and store your labels.

This will be in 7.0.1750.9, probably posted later today or tomorrow.

OK i need a clarification... in the AUI'TEXT parameter there are sub-elements defined by "Label=" "Cmd=" "Id="

It sounds like you are returning the "CMD" element which could indeed contain a "&" accelerator. Didnt we agree to return the "ID" element?

The plot seems to be thickening...

Indeed, the ctext parameter (what you're referring to as AUI'TEXT) does contain all those elements when you create and/or modify the TABX control. But I'm not aware of an "id=" field in the labeldef string. What we do have is a "labelid:" prefix to identify the label to which the subsequent labeldef applies, but that only applies when modifying existing labels or adding a new label to an existing TABX control. In that case, the labelid value can be the label #, or its label text, or its cmd string.

We're already (as of 7.0.1751.7) returning the label # (in the cstatus parameter), and now (7.0.1751.9) the plan is (or was) to return the label text in the ctext parameter, thinking that would be the easiest way to identify the panel if the panel # wasn't useful. If you prefer, we could just as easily return the cmd string, although my inclination would be that the label string would be more intuitive.

As for the "&", I think you may be confused. The "&" is part of the label text, not part of the cmd string. It defines an accelerator key that can be used to select the panel instead of clicking. In my example above, "&Two" displays as "Two" , but when you hold down the ALT key, the accelerator keys in the labels get underlined (as in the image below). If you then hit the key in question, it will select the label, causing the label's cmd string to be transmitted. The cmd string does not treat "&" as anything special, and it has no connection to the accelerator key mechanism.



If you're using accelerator keys in your labels, then presumably you're storing them as part of the label, and thus it seems to make the most sense to include them in the label text returned by the new-and-improved CTLOP_INFO. (But the way this conversation is going, I suspect you've got other ideas...)

Sorry you're right the accelerator is in the "Label=" element. However i was actually using as a reference the following example out of the manual to specify the "ID" of a panel which is the source of all of this confusion! (see below). So circling back to the beginning - are you returning the value of "Label=" or "Cmd=" ?? TBH returning the value of "Label=" is no help to me since its just a string descriptor and I cant match that to anything. If anything the CMD element can have more value. But it seems we are just circling the wagons at this point and while I appreciate your efforts i dont think any of the proposed options will work.


! start with TABX global options
tabdefs$ = "@style=0~" ! std modern style
tabdefs$ += "XbtnVisible=1~" ! "x" (close) button visible
tabdefs$ += "XbtnEnabled=1~" ! close button is enabled
tabdefs$ += "XbnTip=Close current tab~" ! tool tip for close btn
tabdefs$ += "themes=0~" ! themes disabled
tabdefs$ += "~" ! end of global options


! add tabs (each with individual options)
tabdefs$ += "Label=&One~"
tabdefs$ += "Cmd=VK_xF101~"
tabdefs$ += "id=One~"
tabdefs$ += "RGBbgClient=200,180,160~" ! active panel/lbl (light beige)
tabdefs$ += "RGBbg=140,130,120~" ! inactive lbl (darker gray/beige)
tabdefs$ += "tip=this is the tab one tip~"
tabdefs$ += "~" ! end of tab 1 options

tabdefs$ += "Label=&Two~"
tabdefs$ += "Cmd=VK_xF102~"
tabdefs$ += "id=Two~"
tabdefs$ += "tip=this is the tab two tip~"
tabdefs$ += "RGBbgClient=150,200,250~"
tabdefs$ += "RGBbg=140,130,120~" ! inactive lbl (darker gray/beige)

tabdefs$ += "~" ! end of tab 2

You seem to have fallen into a crack in the documentation. Or wishful thinking on the part of whoever wrote that sample code!

I was looking at the documentation page for the TABX labeldefs which has no mention of an "id" field, and it does not appear to be stored anywhere internally. It's basically just being ignored. Perhaps it was an idea that never quite got implemented (other than in that bit of sample code)?

So at this point I'll reverse my prior inclination towards the label text and suggest compromising on the returning the cmd string instead. As you rightly point out, obviously your program needs to be able to trace that back to the actual panel. But unfortunately you'll have to manually translate between the cmd string and the resulting exitcode, since even though chances are extremely good that any program using TABX would use VK_xF### virtual command strings, it's not mandatory. So it's not clear how AUI_CONTROL could divine what form of the cmd string you're using within your programs. Although assuming that you are using a consistent VK_xF### format in the label definitions, it should be pretty simple for you to convert them back to an exitcode value if that is in fact what you're using to identify the panels with. Is that an acceptable solution?

Ahh thats me always falling into documentation cracks!!

Yes i do use the Vk_ nomenclature: TAB'TEXT += "Cmd=VK_xF"+STR(CMD)+"~

And Yes - i can easily decode the value back to the original request so that will work! But i dont want muck up the operation if that is going to cause an issue with existing behaviour for other vendors.

Ok, here's the update (client/ATE side only) ...

ash-7.0.1751.9-w32-upd.zip
ash70notes.txt

Thanks Cap i will try to get this tested out here soon.