ShaunR

You probably have the following in the LabVIEW.ini file

I'm not sure how many were added over time but wow, that's a lot of abilities. I was confused with the few I knew of in 2009. Kudos for enumerating them regardless of LV version-that's sweet! I remember my original forays back in the day just to prove I could write them then forgot about them because they were just awful to create and maintain. When it comes to Xnodes/controls. There is only one aspect that I'm particularly interested in and that is a replacement for a polymorphic VI. I have been thinking for a while that having a tool for creating a xnode that replicates a polymorphic VIs behaviour is quite doable - define terminals, select supported types for each terminal along with a "insert your code here" VI and press "make" but then I look at creating an xnode and say "nah. Too hard" I'm a bit disappointed that NI have just made a rats nest bigger rather than trying to make creating xnodes easier. It was an attempt to placate those of us that wanted to create our own native controls and indicators after all. Hopefully with your fresh enthusiasm and new interface, people will add plugins (hint, hint) to automate various common tasks beyond template creation to make Xnodes a more common and viable solution.

I think you may have problems getting feedback as it is really a question for lawyers. I will say, however, that I have software that I own the copyright to and I have not registered it in either the US Copyright Office or the UK Copyright Office (the latter is more applicable to me) but at least it is an answer.. I think in your case just send them an email and ask or choose one and they will tell you if it is wrong but my interpretation of your snippet is that it would be "Literary Work" unless it is something like billboard software. Software is recognised as "Literary Work" in many international agreements and "Work of the Visual Arts" just sounds like they are trying shoehorn media copyright such as public displays and performance into a separate section for software. So it depends. What does your software do?

You didn't migrate make Darins change of replacing the "2" constant. The back-port has the original bug.

Can you give an example? Most people fall foul of the change in path between development and executable.

Maybe move this thread to the CR "uncertified" as it is an ongoing development? What licencing are you planning to apply, just to clarify!

You mean LabVIEWTM, LabVIEWTM, LabVIEWTM

One thing to be aware of is that the OS bitness and LabVIEW bitness are separate. That is. If you use LabVIEW 32 bit on a 64 bit platform you must use 32 bit addresses. Similarly, LabVIEW 32 bit can only load 32 bit binaries (DLLs) and LabVIEW 64 can only load 64 bit DLLs. You need to take that into account since LabVIEW 32 bit and LabVIEW 64 bit require different sized structures, are aligned differently and require different binaries. Usually in the LabVIEW code we have a conditional disable structure with different allocations for each bitness if we are passing embedded pointers. Additionally, we have to supply two binaries if we are to support both LabVIEW 32 bit and LabVIEW 64 bit.

The SQLite API for LabVIEW works as far back as 2009

Why not?

NB t/pe/pp = threads per priority, per execution system TIL. 1. They have bumped up the max to 20 t/pe/pp (2014) from 8 (2009) although the default seems still to be 8. 2. You can indeed set more than 20 t/pe/pp TIWL (Things I will Learn) 1. How high can it go before nasty things happen. 2. When setting executables' ini files. Does labview cumulatively allocate threads as more executables are run? 3. Is there a more up-to-date document that describes LabVIEW threading? and you will, given sufficient non-trivial applications. bloatware" FTFY

You just made me clear my nose with coffee

IC. Never found where it was left after you parked it (see what I did there? ) Reading back over it; seems we covered most bases so hopefully NI didn't put the brakes on it. (oh dear, I need some coffee)

Are you saying that the # threads can be increased past 8 per execution system and create more execution systems by editing the ini file? i.e you can surpass the absolute maximum number of allocatable threads of 200 that can be achieved if you maximise all in the threadconfig.vi, Can you clarify what you mean here? Another solution that I've used quite often for comms is to use other 1 and other 2 execution systems for read and write respectively. That effectively doubles the number of available threads and removes them from the usual thread pools used by everything else. What was CAR 313508 for anyway?

In computing, a computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely called again ("re-entered") before its previous invocations complete execution. Rules for reentrancy: Reentrant code may not hold any static (or global) non-constant data. Reentrant code may not modify its own code. Reentrant code may not call non-reentrant computer programs or routines. Citaton given. Can we please move on now?

Because they were written when it was the only way to do this kind of thing. Remember. It is only a problem with Shared re-entrant just don't set your methods to shared re-entrant and it will work as expected. The easy way out for NI is for LabVIEW to break the VI if you try and set shared clones when calling a pre-allocated re-entrant VI the same as they do with subroutines.

I know. I reckon it's probably the reason that that function is, and always will be, private Doesn't hurt to sow the seed of the thought though-engineers love a challenge I've just been through a lot of this platform rationalisation with a replacement for the NI licencing system since I need one that works on all the platforms, not just Windoze. I was lucky enough to not have to link in to weird and wonderful static libraries, though. I think I could probably hack together a DLL that could get x windows forms and probably whatever the equivalent is,on Mac; if push came to shove. I'd rather NI did it properly though.

Well. You, malicious bots, hackers and Viagra spammers PM me your IP address and I'll remove the block.

Unfortunate. Proxy? It's the MDI Toolkit for LabVIEW but with bigger pictures and datasheets.

Pretty much everything in this Toolkit I don't know how they will implement it on Mac and Linux, although similar capabilities would be nice.

I have a solution. It works. It even worked when the force destroy was just reserved for future use in 2009 (although you still seem to be missing the leaking point). As I said previously. We didn't used to have to worry about memory management until queues et. al were introduced - which is where we started with this little rabbit hole..

Sure. Obtain returns the actual queue reference rather than a copy.

You see? That's why this is such a problem for people. Re-entrancy is meant for non-blocking parallel execution. Using it as a memory storage method is just an abuse of its apparent behaviour. I think people looked at LV2 style globals and thought they would be clever and use re-entrant VIs ina similar way. There is one huge difference with a LV2 global though. It is a singleton! When I use re-entrancy it is because I want things to be non-blocking. I use storage methods for memory storage like the class private data which was intended for that. That doesn't help the OP, though since it is a NI toolkit that has this so the only sane recourse is to not set class method to re-entrant and put a huge note in the method diagram of why. It is exactly the same as malloc for memory leaks. Obtaining a queue reference creates a copy of the ref so the programmer is forced to reference count and twin each obtain with a release.Keep obtaining and miss one release and you will run out of memory eventually. This was such a problem wherever I went to work, I created the Queue action engine that encapsulates the queue primitives to ensure there is only ever a maximum of 1 reference. Download any of my software and you will see it where queues are used. Amen. But I would argue they are not exceptions. The maxim is "never use re-entrant memory storage" and all those you describe are not re-entrant (well, FPGA might be-I don't really know what you are referring to there). I wouldn't go as far as say "never store state in a VI" otherwise you are back to global and local variables and those you list were invented to address the issues with those memory storage methods.

Not so. Memory leaks were introduced with the queue, notifier etc primitives. Before then there was no way to leak memory programmatically, only allocate huge amounts to get the bulldozer. The thread safety issue was introduced with pooling of re-entrant VIs. Prior to that there was only pre-allocation re-entrancy and no you don't get similar issues with pre-allocated since it is lack of control over thread execution order of an instance that causes the issue which is non existent with pre-allocated.To replicate in classical LabVIEW you have to call a pre-allocated, re-entrant from a shared clones VI. If you wan to go back further, there was only a single virtual context so you could have executables share global variables