Leaderboard

Just thought I would pass this simple observation when using the 2 button dialog. I created a dialog where I wanted to warn the user to be careful when selecting a certain operation. In order to make sure they did not accidentally select OK, I reversed the messages so the cancel would be the one that defaulted to having it's key focus set to true. Then, I used the 'T button?' output to select the case and put the code to do the action in the false case. I then patted myself on the back for making a safer UI. Along comes the "user" and they select this operation from the menu then panic thinking the computer will explode if the do the operation. But, instead of pressing the 'abort' button, they CLOSE THE DIALOG BOX! Which, of course returns a FALSE for the 'T button?' and the code is executed... Now, I know I am a fool for not seeing this possibility, but I just thought I would share so perhaps someone else doe not make the same mistake I did... -John

"if you try to idiot proof your UI, they will build a better idiot..." I foresee myself quoting this many times in the future... -D

I would argue that it shouldn't be cached, by default. Almost. Only as long as there are no dynamic calls in the call chain -- there is the possibility that dynamic calls using VI Server CBR nodes could cause the same WaR bug to appear. The difference between a bug and a feature can be debate without end. I don't want this performance "feature", because it causes a "bug" in my code. Since this constraint is not published, I feel it's a bug. Dynamic dispatch VIs cannot be set to preallocated reentrancy -- it will cause them to be broken. I would argue that if there's a use case for a performance improvement whose implementation has constraints on modes of use, that this be made an optional, Boolean argument (named something like: reuse messaging queues for minor performance boost). Cheers,