Ravi Beniwal

I believe you have to be a premium member to be able to edit/delete your posts.

Is there any possible (special) use such an array? If not, there is no reason to design it and it is a bug. It certainly hurts the brain when you try to picture it

Hi Olivier, I ran into these issues recently. Like all generalizations, this one may be wrong, but here was my observation! When you are switching from an XP machine to a Win7 machine, there is a pretty good chance that you are also moving to a higher resolution screen. I noticed that the system and dialog font on Win7 machines are set to a larger font then XP machines so that the physical size of the letters doesn't get too small on the higer resolution screens. To accommodate this larger test, all controls grow (and not always nicely), overlap, and just look weird. In this case, since the probes will always be used by nice friends like us and not in delivered products to customers (where you don't know who dislikes what), you can safely change the font on all text on the probes to a common fixed font like Tahoma 13pt or something. Within the development environment, we care more about getting access to the right information for debugging and wouldn't mind that you deviated from the recommended Dialog or System font.

Hi Alex, In your FPGA Control Loop, you have the error wired to a shift register on the while loop. In case of an error, you are enqueuing an error command, but are also passing the error from that iteration f the while loop to the next through the shift register. So in the next iteration, the Dequeue Element sees the error wired in. It does not execute to pass on the "error" message you enqueued, instead it passes the control with an empty deueued element, which of course will give you an empty string. That is why the loop goes to the default typo handling case. Fix: either do not use a shift register for error on the while loop, or clear error in the "Error" case, where you are enqueuing the "error" message, so that the Dequeue element can work properly and see this message.

You could use the value (signalling) property of your Done Calibrating button to stop the event loop in response to the shutdown message from the other section. That way the same button can respond to the user click as well as outside messages.

Adding a filter for VI state sounds like a good idea. I'll look into it and any optimization for adding large number of VIs to the tree. May be use add multiple items to tree instead of adding each item individually. But during a refresh, it has to get the properties of each VI and update them. Well may be not, if we specify which properties (columns) will change during execution and check only those. I'll post an update or list of issues

It was the while loop around the event structure that finished execution. The event structure is put inside the while loop so that we can give it a chance to handle more events that might have occurred since its last execution. By not returning control to it, we took its ability to handle the events away. I see your point too! It probably should have locked down the front panel once it started handling the event and then should have unlocked it, once it was done. But I'm not sure if this is the behavior we really want. Let's say the loop is busy handling one event and you click a button, which is supposed to lock down the FP. If the FP is not locked down right away, you could generate many other events before the button click event case gets a chance to execute. To avoid this, you could enable locking down FP for the current event. But then, where do you stop? This strategy would have to cascade through all the events, because you won't know when a user might throw in a couple of clicks. Ideally, this shouldn't even be an issue because your event handler should receive all FP events and then send them for processing elsewhere. The event loop should finish only when the VI is "on its way out" and at that time, the FP should be not be expected to let you interact with it.

Turn off "Lock front panel..." for the Done Calibrating:value change event and this will be fixed. When you hit Done Calibrating once, it shuts down the event handling loop. When you click it again, it locks the FP until "this event case completes", but the event never gets a chance to handle this event again and the FP never gets unlocked. That's why you can't click on Stopped? 2.

Agreed; I just didn't wanna miss anything!

Hi MikaelH, we did use the "Get Nth Line" to count the number of lines, but that takes some iterations (and time) to come up with the number of lines and it didn't work for Mark. His solution works pretty well, where he is calculating number of lines from the font size. The Text.ScrollPos property takes in a U32 number that can have a maximum value of xFFFFFFFF or d4294967295, which is the "crazy large number" that we were using. If you wire Inf+, wouldn't it be converted to the same U32 max of 4294967295?

I guess while oversimplifying it, I totally missed that you were using the same crazy large number to scroll to the end. At least now, we didn't leave any aspect of scrolling string indicators, for others' sake!

Hi Mark, If keeping the scroll bar position at the bottom is all you need, you do not need to worry about the font or the indicator size. You just need to (try to) change the scroll position to a crazy large number. It will automatically take the largest value it can. Here's you VI, modified. Auto Scrolling String Indicator.vi

Hi Mark, Now I understand what you meant by moving the scroll bar to the end. I thought that this is a case like reading a large body of text and you wanted it to scroll as the user you read through it. I didn't realize it just had to keep the latest text visible, as it was added, if the scroll bar was moved to the bottom. Well, I guess now we have two solutions that could help at least two people

Here's the Task Manager R5 saved for LabVIEW 2010! LabVIEW Task Manager R5 - 2010.zip

Sorry about that! When I downloaded Darren's VI, it went straight to my Downloads folder and was being linked from there. I've fixed that now and have actually included it this time Here is the updated R5. LabVIEW Task Manager R5.zip I've added grouping by class/library that you suggested. I've also added a Close FP button and improved the numeric sorting of the data tree. Please let me know if anything is missing this time or if you have any suggestions/comments.

pixlr.com/editor is pretty good and has most of the features of Photoshop. I've been using it a lot lately. It certainly load way faster than Photoshop.

clicking on the combo box (or what looks like a combo box, but is just a string control) can pop up a list box, where you can set different colors and when the user clicks on the list box, the value is copied to the combo box and the list box hides.

Thanks Darren! I have included your VI in the solution. Here is the latest package that include most of what we have discussed so far. LabVIEW Task Manager R4.zip After including Darren's VI for searching statically referenced clones, we no longer need to include the Clone VIs FG.vi in the reentrant VIs that are statically referenced. But if you put this FG into a reentrant VI that is called asynchronously, it will make sure all clones are found.

So Mark, how do you AutoScroll when the user moves the scroll bar to the end? If the scroll bar is controlling the scroll position, wouldn't the text automatically followed the scroll bar to the end while you were moving it there? I guess adding another button at the bottom of the scroll bar could be more intuitive. Here is what I have so far. Number of Lines in String Indicator.vi String AutoScroll Main.vi Can you send me some sample text that you are working with?

OK, here are the updated VIs. Now "Number of Lines in String Indicator.vi" doesn't get if you resize the control or change its value, which could change the number of lines while it is calculating from the initial state. Number of Lines in String Indicator.vi String AutoScroll Main.vi

You mentioned that the modules are communicating with each other via messages. But have you separated the part of that receives and responds to the messages and the part that does the heavy lifting? Since you are concerned about the response time from the module, I'm guessing the response you are concerned about is not the result of this heavy processing that module is doing, otherwise you'd just have to wait for it to finish, unless you want the last calculated value from it. The example you shared has a SubVI in a Main VI loop. If the SubVI takes a long time to pass the control back to the Main VI, you should have a different loop in this Main VI that is supposed to handle messages/events. About measuring time, it is a good idea to use the Get Date/Time in Seconds to read the current instead of the Tick Count (ms) as its value can roll over during execution, which will throw off your measurements.

Good catch! I guess I just sent the line index out and not the number of lines.

Hi Mark, I created a VI that will count the number of lines in a string indicator. Number of Lines in String Indicator.vi The VI below will let you test it out. Currently, when you change the value of the string control, it recalculates the number of lines. String AutoScroll Main.vi I tried to test it while resizing the control with the pane, but I need to put some more work into it as it doesn't like the conditions changed on it while it is calculating. I'll add that and send you the VI again. As for the scroll bar, I'd suggest adding a separate scroll bar as it will give you more control over it and also you can catch the value change event for the scroll bar.

interesting! I just happened to do exactly that this morning. Great minds think alike, I guess Would one always know if he is working with higher-numbered clones? AQ suggested otherwise!

Can you elaborate on the design? Is it just one main VI with one SubVI in it? Is the SubVI being called in a loop? Can you post the application, or a simpler version of it?