drjdpowell

Tone of voice doesn't come through on the internet, X__. You need to be more clear or start using emojis 🙂 AQ, I'm thinking about the Project changes, as I had not appreciated how significant the change is.

I think you need to give the User a choice at step 2 of what to do with the loose files. In my case they are just deprecated VIs that never got deleted (deleting files in Current Gen is very inconvenient). Step 3 need a choice too, as adding the shared files to one of the projects will usually be the right choice.

JSONtext was a single project, but for some reason the conversion tool created two projects: "JSONtext" and "LooseFiles_JSONtext for NXG", plus a "Shared" folder, which actually held the JSONtext.gcomp. I fixd the issue by: closing NXG moving the floder with all the JSONtext files into the same "JSONtext" folder as teh JSONtext project reopening the JSONtext project "Excluding" (bad terminology?) the now-broken JSONtext.gcomp "link" (was annoyed there was no way to fix the link by pointing to the new location) "Add file.." to add JSONtext.gcomp from new location (was pleasently surprised that this then fixed all dependencies without LabVIEW CGs endless dialogs)

So where is a good forum for discussing NXG? Here on LAVA? I'm not one who likes short 1 on 1 private talks nor am I in to "workflows". But I could make lots of feedback on NXG if I have time to craft posts. Right now, for example, I'm trying to make sense of the NXG Project created by the conversion tool from my JSONtext library. I'm completely stuck at not knowing what a "Link" is, and how I can get the JSONtext.gcomp to not be a Link. As a "link", namespaces don't seem to work (I can create a namespace, but not add anything to it) and I suspect this is because a "link" is some kind of leser membership in my project. Maybe. Who knows. I cannot find anything in the NXG help on what a "Link" is, or how to open up the JSONtext.gcomp as not a link. In general, I'm experiencing a lot of "blank stare" moments in trying to figure out this software. Can it really be designed for new users and non-programmers?

Conversation dead.

I think you'd get more chance of a response if you posted on the Actor Framework forum. I don't use AF or DQMH, nor have I looked at your code, but is it wise to try and combine different frameworks? Frameworks are designed to support different design philosophies, which are not necessarily mix-and-match. If DQMH makes sense to you while some of the AF stuff doesn't click, why not just use the DQMH?

JeffP, in the interest of not letting this conversation die, can you present some positive features of NXG that improve over LabVIEW?

I didn't think NXG had a control editor yet.

Why not just use the new buttons, with icons, which you can find in the pallets now that you have installed the package? These buttons are created from the system button, in order to get hover states. System buttons don't support the button colours, unfortunately.

That's because SQLite and PQ have different approaches, and I'm closely following how they work. One could think of coming up with a combined API, but that might involve compromises.

What version are you using? The latest version in VIPM is 1.9.1.33 Can you post a VI showing the behavior?

No, there is no circular references in JSONtext or this library.

I'll have a look at your Demo when I get the chance, to see if I can find a work around (other than not putting actors in Libraries). Unfortunately, "Messenger Library" is built on the principle of doing asynchronous things without being blocked by "Root Loop" (a little known but critical flaw of async calls in LabVIEW), and that restricts how I "launch" actors. The NI "Actor Framework" uses the same/similar method; I wonder if it has a similar problem.

I'm guessing this is an edge-case builder bug. I realize, though, why I have not seen it; I am hesitant to use LabVIEW Libraries. I don't put typedefs in libraries at all if they are going to be used by a component independently of the other stuff in the library, and I rarely if ever put a Class inside a Library. Libraries should be a good thing, but the "load everything in the dev environment" is a real negative. Here, the bug you are suffering is in the builder code to strip out the useless connection to the unused library elements. That builder code shouldn't even need to exist, as there is no reason to load code that is not used. The fact that your IGOR Library has "Utilities" and "Common Typedefs" tells me you are using LabVIEW Libraries the way they SHOULD work: convenient collections of things that you might use some of. But Libraries are too flawed to be used as they intuitively should be. Hopefully, they will address this in NXG.

Question: if you take an actor that has the problem, and remove it from its class (making it an ordinary non-dd vi) does it still not build? I want to know if this is a problem that requires DD and your library typedefs together, or just the typedefs.

Have you tried building your actors individually into EXEs? To see which one breaks. Make a new build and make the top level vi only one of your actors and see if it builds. Then swap in a different actor. Hopefully, they will all build but one, which narrows down where the problem is.

Jeff, what is a good place for NXG feedback? There is a beta forum here, but it is extremely quiet.

I strongly doubt TCP delays are your initial problem. These are designed delays of up to 200ms, so they can't cause a many-second delay.

Actually, I like the new Array sizing where the bottom edge is not the bottom of the array. in current gen, the fact that an array has a "coarse" sizing causes issues when the arrays are set to scale with the pane size. After several resizes the accumulated round-off errors build up and the array can be very out of sync with the panel size. Having a size that isn't forced to be an integer multiple of element size means that that scaling will work much better. Once, that is, they actually have panel scaling and splitterbars and the like in NXG (I could not identify any such in 5.0).

I think LabVIEW CG doesn't automatically resave files, when opened in new versions, anymore, so that may be the reason.

Hmmm, one download, eh? Nobody use SQLite here?

Can you run a standard LabVIEW TCP example between you two machines? That would tell me if the slowdown is in Messenger Library itself, or in the lower level TCP layer.

An annotated handling of the "From Starter: Connect to service" message. The Negotiate Version subVI (which talks to teh Server) is taking longer than the default timeout.

Are you using the debug tools? Such as Tools>>Messenger Library>>Actor Manager, where you can open the diagram of any running actor: Here I'm running the TCP example included in Messenger Library. You can open the TCP Client actor and see where it handles the message:

This is Issue 34, I think?