2nd DeferpanUpdts should be set to False, once the change is completed.
Regarding redrawing, have you delete the REPO class Menuoptions.vi from "new" structure that I've pointed out before?
And question from me:
Does anyone know how to choose implementation on the class we want to use? What I want to do is to use cRIOREPO.lvclass:Customview.vi, but LV uses the NISE_CEF_Hierarchy...CustomView.vi...
during some testing of the CEF Configuration Editor Sample Project I have noticed the following error occuring when removing elements from the tree structure (see also attached png file):
Error 1000 occured at Invoke Node in NISE_CEF_TreeControl.lvlib: LoadUIStandardEvents.vi-> Advanced Configuration Tool.lvlib: Configuration Tool Main.vi "
The VI in not in a state compatible with this operation
Since I am just using the sample project and simply add or remove elements the issue seems to come from the framework itself and is not caused by custom code.
Does anyone have the same experience and/or has found a solution?
I think the UI VI in the subpanel just doesn't get enough time to get aborted before being manipulated further in that LoadNodeUIStandardEvents.vi sometimes. I suspect that it is the Run VI invoke node in the very end that throws that error if the UI VI it tries to run is still running. You can set control values while a VI is running. So, all those invoke nodes won't throw an error. Anyways, we can simply first make sure (wait) until the aborted UI VI is indeed aborted (idle) before doing everything else to it.
Oops! It says right there in your screenshot that it is Abort VI method that failed, which means that it tried to abort a VI that is not running at top level! Does it mean, the Execution.State property node can be lying to us?!
Short Name: Abort VI
Requires: Base Development System
Class: VI Methods
To Use: Create a method.
Aborts the execution of a top-level VI.
This method returns error 1000 if you call it on a subVI. Otherwise, this method is similar to pressing the Abort Execution button on the toolbar.
So, does this method sometimes consider the UI VI in the subpanel a SubVI, not a top level VI?
thanks for sharing your ideas styrum. I am also not quiet sure why the Abort VI method returns the error since this behaviour seems to be pretty random. It does not really matter how fast you perform an action on the tree structure. After manipulating the tree for a while the error will eventually appear.
The question is whether one can fix this or whether it is just an issue of the framework itself and one basically has to accept it
CEF is open source, so you can fix the issue. To do this is first create a issue: https://github.com/NISystemsEngineering/CEF/issues
Once the issue is created you can fork the code, make your fix and them make a pull request.