X___

Still don't get how this is my answer, in particular to the "running VI arrow" in the calling VI and the stopped CORE.vi question. I think I do remember indeed that putting a breakpoint in the CORE.vi and stepping through it might have prevented it from "aborting" (for lack of a better understanding of what is happening), but then, when that CORE.vi is/was called from within the main VI, things were working fine, so it doesn't really explain anything for me. But to some extent, this doesn't matter anymore at this point.

Follow-up: replacing the 3-button dialog window with my own (working in essentially the same way, if a bit cleaner) solves the issue (for now). I still would like to understand what happened with this VI...

I am discussing run time behavior. I am not editing the 3-dialog button VI. The snapshot I showed is the end result of the app running (and getting stuck). The FP of that dialog window opens up via an invoke node in that dialog VI (the first part is formatting, as I mentioned in the previous post - the VI can be checked in vi.lib), and then there is a simple event loop that waits for a button click, which ends the execution and closes the VI. So when that dialog VI is reached in my Notebook VI (at the green arrow location in the original post), the dialog VI executes, formats itself, opens its window, and by some magic, quits the event loop without a click and doesn't close the window. I have put error indicators in that 3-dialog CORE VI to check whether any error was generated, but couldn't see any, which makes that (putative) behavior so puzzling to me.

I had to read this to learn something new (about bugs and wasps): http://www.labviewcraftsmen.com/blog/the-root-loop However that post says that the 3-button dialog (which I am using) does not require to run in the root loop... I generally write my own dialogs, but this one is convenient (although style-wise, pretty dated) because of all its fancy formatting. I'll try with my own regardless, just for verification purpose.

I am staring at this: which shows a snapshot of 3 VIs, two of them being in vi.lib/Utility/error.lib VIs (visible FP), the other one being a subVI in a library of mine. The snapshot illustrates the puzzling situation that I am encountering: Three Button Dialog.vi, whose state is idle as is clear from the snapshot (but is also confirmed by the LabVIEW Task Manager), is however "running" as indicated by the green arrow in the calling VI (whose BD is shown in the back). The "Close Notebook Dialog Window" is nothing but the Three Button Dialog CORE.vi of the error.lib library, and is also idle. In other words, the calling subVI is never stepping out of this situation and the only way for me to recover is to abort the VI. Question: how is THIS even possible? Background information: First of all, I wished I could boil this down to a simple example that I could share, but I haven't been able to reproduce this yet in a bare bone project. Now, the weird thing is that this situation occurred after what I thought would be a simple refactoring of my application, namely dynamically launching my consumer loop, which itself launches the Notebook VI whose subVI is now unresponsive. Before: Main launches Notebook dynamically. User closes Main. Only Notebook remains live. User clicks Notebook's "close box" which call the 3-button dialog. User clicks "No", Notebook closes. After: Main launches Consumer loop VI dynamically. Consumer opens Notebook dynamically. User closes Main which sends a "Quit" message to the Consumer loop, shutting it down. Only Notebook remains live. User clicks Notebook's "close box" which call the 3-button dialog 3-button dialog is idle, Notebook is stuck waiting for it to finish. Something is going on (or rather is not). What could it be? LabVIEW 2021 SP1 64-bit Windows 10 Edit: I forgot to mention that none of the VIs above are re-entrant and that the 3-button dialog CORE.vi is supposed to run as a modal window.

As if there were no such personalities on NI forums...

I am certainly not going to rewrite a Plot Legend, as there are so many functionalities I am relying on (however buggy they are), that this would be way too much work.

Another interesting tidbit about the Index Display is that if you edit its Description and Tip, the Tip does show up as expected when hovering over the index (and its description in the Help window), but if you have not set a Description for the array itself, that index's description will show up for the whole array (but not the index's tip). Define both Description and Tip for the array AND its index, and things work as expected. It's tough to write code that does behave properly in all cases...

At this point I am just showing the index display at all times and hiding it with a disabled button whenever I don't need it. I am not expecting this to be fixed before 2030 and since I am not planning to upgrade to 2022 and later, that will be it.

As the title says, you can show and hide the plot legend index display (it is an array after all) in Edit mode, but there is no property to do that programmatically. Since the NXG style plot legend scrollbar is buggy (see this report and the linked thread), providing this index display as a backup for users to navigate the plot list in the absence of a mouse wheel, is not elegant has its visibility cannot be controlled (AFAIK).

The bug has been described a while ago here but might never have been submitted... It is still present in LV 2021 SP1.

As described here, I just discovered: https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/editing_the_shortcut_menu/

This looks very interesting. I am curious about your mention of HDF5 support. I am using the h5labview wrapper, which is not really updated anymore. Are you developing a complete support (read/write) of the HDF5 format as well? Which version are you going to release it in? I am not planning to upgrade past 2021 due to the new NI licensing scheme (can't pay for the hostage fee with our meager grants if our Department decides to drop LabVIEW from their supported toolkit). Kudos for the project and developers!

Right... Feels like the 100 flowers campaign to me. They will learn their lesson quickly.

Just to make it clear to those who did not watch the video (or attend the meeting): these were LIVE inputs from the audience, which were fed directly into the presenter's screen. But, yes, I don't think the "distribution and licensing" comment was addressed by NI's new licensing policy. But again, he just laughed all these comments off and went on to the next question.

I am not using Linux or Mac.

Mixing text and graphics, as well as allowing style and color, undo and redo, etc. is precisely why I am using the RTB .NET object. Care to enlighten me how you can do that otherwise in LV?

The fix, BTW, was quite simple: delete the offending "u" character in the header (using Notepad ++ or any neutral editor). This fixed the problem with Word or the .NET rtf loading method. In the meantime, I have switched off the Windows beta function.

I found clever to try out that setting, only to realize the hard way that it was messing with the RTF .NET support. Namely, saving a .NET rich text box content to rtf generated a file with header starting with {\urtf1\ansi... instead of {\rtf1\ansi..., which prevented reloading the file in the rich text box. (similar to this error report: https://supportcenter.devexpress.com/ticket/details/t993371/import-from-rtf-richeditcontrol-does-not-correctly-display-specific-characters-when-the) Not only that but Word would not open that file as rtf, but as plain text (which made it fairly easy for me to spot the culprit). Buyer beware.

The problem with that talk is that it says nothing about what the stated goals of NXG were, why the progresses were so slow, what their roadmap looked like at the time they canned it, and what their plans are for the future. Instead, there was a mention of their audit by a bunch of Agile zealots, a free advertisement for online post-it boards and other kind of nonsense about why the lessons they learned (essentially regurgitated slogans) should be taken very seriously by the audience (no kidding). And then there was the now infamous series of botched polls and Q & As which of course they have diligently ignored ever since. Not that it departs much from what the scripted presentations at NI week used to be (at least the few I watched online) so it shouldn't have been a surprise that it would end up that way. I am ahoping that those really interested in actual facts managed to ask him those questions later on (if so, please tell us). In my world (academia), the most important bits are gathered that way, by post=presentation discussions. If your format doesn't constrain presenters to be around during the whole series and be available for discussions, this calls for changes. This being said, thanks for posting those presentations!

Hmm... I guess not anymore: https://www.forbes.com/sites/martyswant/2022/01/18/ibm-chief-marketing-officer-carla-pieyro-sublett-departs/?sh=18db8f8b4daa

I have no idea why the name Boeing seems to be colliding with that of NI in my mind lately...

You will love this: https://forums.ni.com/t5/LabVIEW/NI-s-move-to-subscription-software/td-p/4215663 In essence: we failed you, but this is because you were not paying us enough, so we will change this, which will be good value for you and us. What was he saying about denying reality?

Thanks. So it is a bit as I feared. NI dumped a bunch of VIs, briefly mentioned them in Upgrades Notes and that's it.

I have jumped from 2019 SP1 to 2021 SP1 and incidentally discovered the existence of new Multiple Errors VIs introduced in LV 2020 after listening to AQ's presentation at the previous GDevCon (which otherwise went right above my head). The upgrade notes only say: Multiple Errors VIs The Dialog & User Interface palette includes the new Multiple Errors subpalette. Use the Multiple Errors VIs to convert an error cluster into different formats or to manipulate the attributes of an error cluster. Digging cursorily into the VIs, I see the use of JSON instead of the ad hoc LV error message syntax, but I am unclear what changes (or not) as far as handling "standard" errors. I am assuming not everything has been rewritten has this would break former code (the Simple Error Handler.vi seems not to have changed and only deals with <append> and <err> syntax. I couldn't find anything in the examples or much in the Help. Do I want to add "Attributes" to an error cluster? How can I take advantage of the new features for better error reporting/formatting?