Yair

One thing you could try is disabling and enabling the port, which often helps, but if I remember correctly, doing it programmatically is a problem, because you have to use a component which only comes with the Windows SDK, which you have to install separately. When dealing with this in the past, I think that after giving it a quick look, I decided to give up on it and just tell the users to do it manually (through the device manager) or restart when this happens (in my case I don't think this was caused by LV, but by something else which grabbed the port, although I have no idea what, because there shouldn't have been anything else there).

I also use multiple event structures in the same BD on occasion, either for handling separate parts of the UI which are in the same VI, or for handling non-UI events. I wouldn't like it if my legacy code broke when upgrading to LV 202X when these features are introduced, but if those features are worth it, I wouldn't be broken up if I was told "you can only use these features if you have a single ES in the VI".

I can't give you a full list (because I don't know it), but for instance:

1. Facade VIs only act when there's an event they're registered for.
2. Resize events not being processed in subpanels.
3. Failing to register for events in a subpanel, because you do it when the FP is closed.
   

Like I said, code.

Does anyone have a clue what going on?

Not without code to look at (although both XControls and subpanels don't always behave like people expect them to).

I find event driven asynchronous comms, vastly superior to the normal methods (

)..

My keen senses are detecting class wires in that example. Shall I call a doctor?

I found it interesting that, oh, unless that NaN is in the data of an object.  Then NaN is equal to NaN  (x=y?). 

 

....Unless you make a copy of the object (x=y? 2):

I'm guessing that this is an optimization - if the equals node sees the same object wire going into both terminals, it probably says "I don't know how long a comparison will take, so I will just return true, since I'm comparing the same object". I think it's a slightly weird optimization, if only because the use case of wiring the same object twice into the node is ridiculous, but that's my guess based on the image. Of course, it also seems to produce inconsistent results in the case of an object containing a NaN, so this can probably be considered a buggy optimization.

Let's make plugins in Quick Drop properly usable - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Supercharge-Quick-Drop-Turn-QD-keyboard-shortcuts-into-first/idi-p/2620153

Has the attachements been removed for old posts?

A lot of them were lost in a server crash a few years back. You can clicking the report link on the relevant post and ask the moderators to look for the file, but I wouldn't hold my breath on that, as I don't know what tools they for that and if it's even still possible. If it's a useful file, then someone else might have it.

Can “reading someone else’s memory” cause an exception?

No idea. My C is limited and rusty enough that I can't say what can actually cause an exception (certainly not inside MoveBlock, which is a black box, although I'm assuming a relatively simple one), so I would just consider that a guess. Like you, I would also expect that if this was possible, then it would be common enough to notice.

One option for rawlukn, if this happens often enough, is to log the relevant params when there's an error and then you can at least see what the SQL looks like, what the pointer is, what the size is, etc.

If I left the columns input on the VI with a empty array of course I can send and save both columns (VI attached), but I can find the way to write just the DATA column.

If the columns input is empty or unwired, the VI will insert each element of the cluster into the corresponding column (by order). If the columns input isn't empty, it has to have the same number of elements as the cluster and each element has to correspond to the parallel element in the cluster, so in your case, the cluster should have one element and the array should have one element, which is "DATE". Of course, as also said, in such a case all the columns which you're not inserting must have auto-generated or default values, or the insert will fail.

There should also be some examples of how to work with these VIs in the example finder.

The error can only happen if:

3) “Remaining SQL tail” pointer returns zero or invalid.

I don't know the SQLite code at all, but a quick look at the image (and the docs¹) brings up the following question²: if the pointer is supposed to return a pointer to "the rest of the SQL", is it OK that you're giving it the full length of the SQL string as the max length? Won't that cause it to read past the end of the SQL string? Is the SQL string guaranteed to have a NULL terminator? Even if it does, does MoveBlock respect that or will it copy whatever's there even if it is a NULL (I'm assuming it would and that then you're potentially reading someone else's memory, which could explain the exception).

1.  at http://www.sqlite.org/c3ref/prepare.html it says:
    

   If pzTail is not NULL then *pzTail is made to point to the first byte past the end of the first SQL statement in zSql. These routines only compile the first statement in zSql, so *pzTail is left pointing to what remains uncompiled.

    
   
2. Ignoring the fact that the doc only refers to a case where it's not NULL (your initial value is, but that's the ** and it refers to the actual value, so I don't know what's right here) and that I don't understand the distinction it makes between the value and the two layers of indirection (it refers to all three and I'm assuming it's consistent).
   

Well, according to what it says, you can get it by calling a specific function from a CIN, but you should keep in mind that CINs are generally legacy tech, so it's possible that something would have stopped working in newer versions. Personally I never saw this window, but I don't really use CINs.

If you want a simple debug window, you can do something as simple as VI which takes in a string input and concatenates it to a string indicator, which is the log. You set the VI to show the FP when called and you're done. Of course, you could get a lot fancier with loggers and debuggers and have levels, daemons, logging to disk, etc. There are various loggers available online.

Once a VI is reserved for execution (or running, which is the same thing practically) the selection list is always cleared - selections only exist in edit mode. To use the Selection List[] property, you have to open a reference to a VI which is in edit mode, which you can do by using either the Open VI Reference primitive or the New VI primitive, which will create a new VI. The property is very useful for performing operations on the selected items.

Attached is the template I usually use if I want to write some quick code for manipulating multiple objects (LV 2009) - it get a reference to the VI you're working in. I believe it was a quick mod from something Norm posted.

Scripting.vit

I would be more than happy to clear out all the spam that I see each day.

Likewise. It worked well when we sorted the old content in the past and I expect it should work reasonably well now. I think it's important to handle this because I think this much spam really hurts the usability of the site (I assume that it should be relatively easy to check how many non-spam posts were posted compared to last month).

Anyways I have the choice to follow a topic and not see all 10+ posts of one I don't really care about...

The bullet to the left of the topic in the new content list brings you to the oldest unread reply in the thread.

P.S. I would also be willing to help with moderation if needed. There's certainly no reason a small number of people should carry the load if more are required. It seemed to work out fine back when we sorted the old content and I also think that the spam attack did considerable harm to the site (although it seems to be letting up. I only see one from the last few hours).

I haven't experienced this myself, but it sounds like this (and look at the link there) - http://forums.ni.com/t5/LabVIEW/large-clipboard-causes-labview-to-hang/m-p/531485?jump=true

Well, while we can't do this in this forum, I see that it has now been changed elsewhere to "Mark This Post as the Solution", which seems clear enough.

Oh, goodie. Our spammers are becoming more sophisticated. Sigh...

To at least be on topic, I can say that while the sixth season did show an impressive rise in production quality (and a cool new opening sequence), I didn't like it as much as the previous ones. Luckily, it also ended the story quite well and there are no plans currently for more seasons, so it won't go down in quality any more.

Update - My contact told me that they did change the theme after I asked him, but the problem was still happening. I was there a couple of weeks ago and saw that someone changed the theme back. I changed it to classic myself and looked at the log files for the past week today - they indicate that the problem didn't happen at all, so I guess that means that I also ran into exactly the same problem, so thanks for that.

I will give some more details again about what exactly I was seeing, in case it will help someone else as well - when this happened, the entire program was still running fine (I could see the iteration counter I added to the loop incrementing and the LED which corresponds to a DI was updating as I changed the DI), but the UI was completely unresponsive to mouse clicks, not just for the subpanel that the current VI was in, but for all the others subpanels as well and for the only button available at that point in the main VI. I had to crash the program through the Windows task manager.

The program would always get stuck at exactly the same point - you press "start" to start a process, the first screen of that process appears in the subpanel and bam - the UI is stuck. Most of the time this would work perfectly (and it worked just fine for a few years on a PC with Win XP, although there it was 8.6 and for the new machine it was upgraded to 2011), but on rare occasions, it got stuck.

What i end up having to do is create a conversion VI that basically uses a case structure to convert the error from the C enumerator, to a labview typedef. What a pain.

 

ConversionVI.png

It should be pointed out that this could be automated by reading the definitions from the C code, making it considerably less painful. There's probably even some code which does this in the LAVA CR or elsewhere on the site.

Use an XY graph and keep the data yourself instead of having the control keep it. The easiest way is to create a fixed size queue, use lossy enqueue to put the data in and then use the queue status primitive to get all the data without dequeueing (note that you have to wire T into the return elements input).

I'm pretty sure I installed the CCT on the 2013 beta and didn't have this problem. I suggest you open the CCT caller VI (should be under LVProjectLAVA and it should be set to auto run) and look at the code. IIRC, it checks the top level VI for mods and uses that to trigger the save and because it's saved last, it never saves it and always sees mods.

I'm assuming that what's happening here is that it's probably stopping on an error or propagating it and then not reporting it. You could probably simply put a breakpoint after the save VI method, then call the CCT and replace the breakpoint with a conditional probe and wait until there's an error to see which VI the problem is in and what the problem is. One possibility is that you don't have access to save one of the VIs, but that's just a guess.

Error 1172 is just a generic error which means there was an exception returned from the .NET call. You have to look at the source string (which is shown in the dialog) to see the actual details of where the problem was, and you can see here that it says that the format of the string is incorrect. I'm assuming that the reason is that either the names there are localized (although I wouldn't expect them to be for something like this) or that they're using characters which are invalid in your locale. You can start by using probes to see exactly where the error comes from (it says "creating", so it's probably the constructor). You should also look through the documentation of the PerformanceCounter class to see which names it expects.

I don't expect that this would help, but it could be worth a try - go into the WindowsPrefetch folder and muck about. Delete the relevant file. Delete all files. Go crazy (actually, scratch that. You should probably not go crazy, and you probably also want to be careful. My understanding is that nothing bad will happen if you delete stuff there, but I'm not a Windows expert by any stretch of the imagination).

I have no reason to believe this will help, but it's the only mechanism I can think of which is affected by the EXE name, and maybe it caches some kind of dependency which screws things up? You might want to keep the original file so that it can be analyzed.