Migration from 7.0 to 8.1 - problems...

[James M]

Hi George,

Could you post a stripped down version of your code (project file, workspace, source, and uir) so I can reproduce the behavior on my machine?

Regards,

[JDG]

Hi, James,

as attachement there is my project. The Terminal.c file contains the LoadLoalizedPanels function with conditionaly compiles sequence.

When you run the program, please type username / password as "servis" / "servis".
The wrong behaviour may be invoked for example by pressing the "LogIn" button on the toolbar again (or by pressing the Login button on Update tab).

Regards,
George

[Alex D]

George:

What you are seeing is the result of a fairly obscure bit of behavior that results from calling InstallPopup on a child panel. In your case, the Login panel that is shown (via InstallPopup) when you press the Login toolbar button, is a child panel. However, when you install it as a popup, it is temporarily promoted to the status of a top level panel (while still living in the list of child panels for its parent (even though it is momentarily not a child panel)). As soon as you call RemovePopup, it is a normal child panel again. Normally, you wouldn't notice this behavior, which isn't really a bug, just a curiosity, however:

In your program you are using the Tooltip functionality from the Toolbox instrument. This activates a timer which (among other things) iterates over the child panels of the panel which hosts the tooltip control. This code relies on child panels acting like child panels. Once you call InstallPopup on a child panel (like the login panel), it will no longer act like a child panel (until you call RemovePopup). The result is an error in the tooltip code indicating that the popup panel isn't a child panel, which (because the error was created in response to a UI event, in this case a timer tick event) is reported through RunUserInterface.

The best workaround is the one you have already implemented (load the panels as top-level panels, instead of child panels).
Sorry for the inconvenience,

-alex

[JDG]

Hi, Alex!

Thanks for your explanation, and your time to resolve this problem too!

Now it is clear the behaviour of cyclically displayed error message due to tooltip timer.

Regards,

George

[LuisG]

George (and others who might stumble onto this thread):

A useful thing to keep in mind, whenever you are trying to debug a library error that might be coming from an open-source .fp module (such as the Programmer's Toolbox), is that if you suspect that the error is coming from the .fp, you can attach the source to your project for debugging.

This is how you would do it:

1. If the .fp is pre-loaded by CVI in the Library menu (like Toolbox, for example) you will have to remove it from there first. Click on Library>>Customize, remove it from the list, and restart CVI.

2. Add the .fp that you removed from the list to your project, so that you are still able to build the project.

3. Make sure your project is configured for debugging (Build>>Configuration>>Debug)

4. Click on Instrument>>Edit, select the module you want to debug, and then click on the "Attach and Edit Source" button.

After this, you should have a debug version of your instrument's source code attached to your project, so whenever you debug it, you can step into its code just like you would with your own source code.

If you restart CVI, you might have to repeat step 4. And, when you're done debugging, you might want to undo steps 1 and 2.

Generally speaking, most of the .fp modules in the CVI\toolslib folder are open source, so this can come in handy if you want to know more about what your program is doing.
Of course, actually understanding the code is a different story... 🙂 for example, I wouldn't linger too long over easytab.fp (fortunately, it's now obsolete).

Luis