John Lokanis

Yes, but I still contend this is a bug. There is data in there that is not available to the programmer. (the last clicked on row) Why? Is there no way to set this in code?

Here are some VIs demoing the issue. When the prompt VI appears, hold down shift and click on any row other than 0 or the selected row. You will see the selection set to the rows from your clicked row to row 0. The programmatically selected row will be ignored. Now, click on any other row (other than 0 or your programmatically selected row.) Close the prompt VI. Run the calling VI open the VI again. This time hold shift and select any row other than row 0, the programmatically selected row or the last selected row before you closed the VI. You will see the selection set to the row between your newly clicked row and the row you last clicked on before closing the VI the last time. Confirmed in both 8.6.1 and 2009. MCLB prompt.vi Call MCLB prompt.vi

In a multi column list box, you can select multiple items (if you set the list boxtox an array datatype) by clicking on items while holding down CTRL or by clicking on a first item and then holding down shift and selecting the last item in a range you wish to select. I want to display a listbox of data and allow the user to select items in this way. BUT, I want to preselect the first item for them. So, all they would need to do is hold down shift and select the last item to choose a range. Unfortunately, I cannot get this to work. Here is what I have tried: I have set the value of the control to an array containing only the first selected row’s element (even using value signaling). I have set the edit position to the first selected row. I have set the ActiveCell to the first selected row. All of this is done before the user is allowed to select anything. But, the issue remains, the user cannot select a range without first physically selecting the starting row, even if that row has already been programmatically selected by the application. Instead, when the VI first opens, the ‘first row’ is set to row 0. So, holding shift and selecting a row selects all rows from the top row to the clicked row. Even weirder, if the user selects a new ‘first row’ when using the VI, whatever the user selects as this first row is remembered each time the VI is called, even if I have changed all the data being displayed and have ‘selected’ a different row programmatically. Anyone know a way to get this to work as desired? Thanks, -John

thanks guys. I think the short term fix is to use the tick counter. the long term fix might involve some of these more complex signaling techniques.

Ok. I see where you are going with this. I am not sure this would fit into my application. In my case, I have a consumer loop that is monitoring a feed from a producer that enqueues data from an external source. The consumer will issue an exit condition in the following cases: The external source reports it is done. There is an error (of any kind). The user presses abort in the UI. The maximum time is exceeded. The consumer loop executes at least once a second to check the time. It will execute faster if there is data to process from the producer. So, I actually want some polling of the time. IF I implement some sort of external event structure, I imagine I would want to simply let it run until timeout and then assert some sort of signal that the consumer could monitor. I would then also need the event structure to have a user event that allows the consumer to abort it if a different exit condition occurs. This does seem a lot more complex than a simple polling style timeout check. But if it is the only way to make this more reliable I may have to try it.

So, in your example, the tick counter is safe to use, even through a rollover, as long as the timeout limit is less than 25 days. Correct?

I know that we had trouble with tick count rollover back in LV4.1. Maybe I was just so burned by that case that I have been unwilling to give it another try. Can anyone confirm that rollover is a non-issue with Tick Count?

I have some processes where I need to time an external device and issue a timeout if that device fails to respond in a certain amount of time. These timeouts can be in seconds or minutes or even longer in some rare cases. I have accomplished this in the past by getting a time stamp outside the loop that monitors the external device and then in each iteration of the loop I get another time stamp, subtract the original time stamp and then take action on the result if it exceeds the limit. I have used the time stamp instead of the tick counter because I am concerned that the tick counter can roll over and cause a problem with my elapsed time calculation. The problem is, once in a while, the clock on my machine is 'adjusted' by the network time service to bring it back in line. If this happens while the loop is running, the time stamp calculation will be thrown off and my code will think the external device has not responded in the allotted time when in reality it still has more time left to finish. When this happens, I issue a timeout condition that is not real. So, anyone have a suggestion for how to solve this or at least make it more reliable? Our IT guys are not willing to disable the NTP service on my machine to prevent these adjustments so I need to find another way. -John

If this is the case, then you paid for one version of LV, got that version, the SP for it and then a whole new version as well, all for one price. So, if you want to continue getting new versions (and subsequent SP) then you can pay the SSP fee. If you don't want to pay, then you can still use the version you actually bought (8.6) and all it's SP (8.6.1) and consider the LV2009 a bonus. That is unless you are considering LV2009 a bug fix to LV 8.6.1. So, when you buy a version of LV, you always get that version and all it's bug fixes. Any way you look at this, I think NI is being quite fair. I have a lot of software that is constantly being updated and bug fixed, but I only get those updates if I pay for ongoing support. Now, if for some reason NI found a major bug in LV8.6.1 and released a SP called 8.6.2, then I would expect that to be free to all LV8.6 licence holders.

I still don't see any way anyone is actually paying for SP1. If you are, can you tell us how that happened?

I thought a new version of LV always came with one free year of SSP? So, the service pack should be free for anyone who bought a copy of LV2009, right? And for those of us who maintain SSP, it is free anyways (or at least covered by the SSP fees) Maybe the student edition of LV does not come with the 1 year of SSP, but checking the NI web site, the base, full, pro and dev suite versions all include one year of SSP in their price. So, who is actually paying for this service pack? Anyone?

Here is a new idea I just posted. Please take a look and Kudo it if you agree! http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Find-needs-to-have-multiple-search-criteria-with-logic/idi-p/1066409#A4046

Send the snow to BC. They are screwed with all the warm weather and lack of snow for the Olympics. I think the snowboard competition is going to have to be done with skateboards this year!

Confirmed! This solution works in all my test cases for my Console app! Thanks to smenjoulet! I owe you a beer at the next NI Week!

Sweet! This works for me. Only caveat is I cannot call it from the command line using start /wait to force it to wait until completion. However, calling it with "cmd /c myapp.exe" does work, will wait and redirection works too. Thanks! now to try this in my real world application and see if Python likes it!

Nope. Back to the drawing board...

So, when calling this from a real console (cmd.exe) you need to use the start command to make the console wait. But, the start command is it's own app so either the AttachConsole does not really attach you to the cmd.exe's console or the GetStdHandle is not the cmd.exe's StdOut. So, redirection fails. What about using WriteFile instead of WriteConsoleA? That might make the redirection work.

Ok, Now I see what I did wrong. I was calling it like this: 'cmd.exe /c "myapp.exe"'. That does not work. Interestingly, however, something like this: 'cmd.exe /c dir' does return data to the stdout of System Exec. So, again it appears that you can attach to the console of the caller but System Exec is more like the 'run' command. Still does not explain why redirection does not work.

No joy here. I cannot get anything back from the System Exec call. It does open a console window and I can see the output in the window as I press the write buttons but when I choose exit and close the app's window, nothing is returned to the calling LV VI. Do you have anything special in your exe's ini file? Weird. I get nothing under XP when calling from either LV2009 or 8.6.1. Maybe this is an XP issue. Can you try this on an XP machine and confirm?

Can you post your exe? I have tried building an EXE from your VI in LV2009 and I cannot replicate what you are seeing with regards to the System Exec. thanks, -John Yes, the original issue was how to block the console while the app ran. And using the 'start /wait' command solved this. But, I think you are right about not really writing to StdOut. I wish I knew a Windows expert who I could ask... -John

I just tried building you exact code into an exe in LV2009 (instead of replicating the functions in 8.6.1 like I did above) and I still cannot get anything returned to the StdOut of the System Exec call from within LV. Are you sure you got that part to work? Also, I think this might be related to the fact that the redirection and piping does not work. -John

Well, you got me stumped. I have tried allocating a console, tried geting the PID of the exe and then attaching to that console and tried not attaching to any console and I cannot get the LV System Exec call to work. This exhausts my knowledge of windows hacks to do something like this. I will leave it to others to sort this out. It's just another example of what a PITA windows programming is.... -John I just tried your method using .NET to write the string. While this continued to work from the command line, I was unable to get this to work from the System Exec call. I can't seem to figure out what I am missing. Any chance you know of a was to perform the AttachConsole within .NET? It would be nice to get rid of any DLL calls...

No problem. It only took me 5 hours of googling the interwebs to sort that out. I wish there was a better way to learn how to use things like kernel32 and .NET functions...

Just replace the AttachConsole with the AllocConsole and drop the input arg.

Sweet! That solves it. So, now we can write a LabVIEW console app! Here is the VI that let's you write to the StdOut of the calling console: Write to StdOut of Calling Parent.vi -John