JDave

Ben, I am still curious. One must infer from this thread that you are using something different (and better ) than a QSM. What is it? David

QUOTE(PaulG. @ Aug 23 2007, 12:48 PM) But wouldn't that just be WONDERFUL??? You could finally fit the entire application onto one block diagram. Oh yeah! :thumbup:

QUOTE(spaceboy @ Aug 22 2007, 10:55 AM) Starting in 8, there are VI Server Methods to return the row (and column for tables, trees, and multicolumn listboxes) from a mouse coordinate. Just capture the Mouse Down event on your listbox, then feed the reference and mouse coordinates to the method "Point to Row".

The startup time has been pretty good for me. The initial launch is good and subsequent launches are great.

QUOTE(PJM_labview @ Aug 17 2007, 10:55 AM) Thanks for the heads up! :thumbup:

QUOTE(BitsLover @ Aug 17 2007, 05:49 AM) The blue cell indicates current cell selection, or the value of the listbox as indicated in the previous post. This updates with mouse clicks, keyboard events (up and down arrows), or programmatic selection. The dashed square indicates the cell that was last clicked on. I seem to remember that you can get rid of it by removing focus from the control. I will try to verify how I did that. The pertinent code is not readily available at the moment.

QUOTE(PJM_labview @ Aug 16 2007, 08:25 PM) Now why have I not paid attention to the scripting events??? Thanks so much, PJM_labview. That works a treat. It looks like it fires for LabVIEW tools (like Hierarchy window and Navigation window, etc.) as well, so if I want to ignore them I will have to filter them. Have you done that before? --- Wait, I forgot about the scripting property "IsSystemVI?". That solves that. Thanks again.

This topic reminded me of this desire of mine. It would be really nice to have a property node or invoke node that returned that frontmost LabVIEW window. You can get all VIs in memory and check if each is frontmost, but this doesn't work for block diagrams. The output of my wishful node would be App Ref - reference of the application the frontmost window belongs to VI name - or the control name if that is the frontmost FrontPanel? - True if the front panel is frontmost, False if it is the block diagram

Ben, I appreciate your description of a bad QSM. Let me restate your points to see if I understood you correctly. QUOTE(Ben @ Aug 15 2007, 04:13 AM) This seems to be common to all QSMs, whether it is in a Queue or a shift register. Not problematic. QUOTE(Ben @ Aug 15 2007, 04:13 AM) Any state can push other states onto the stack before they complete. All cases have the ability to manipulate the queue of actions/states. Hard to predict and track how program moves through states. QUOTE(Ben @ Aug 15 2007, 04:13 AM) All state involved in the application are implemented as cases. No distinction between true state of the software and actions to be performed by the software. Bundled together in the architecture, making it hard to maintain or change things. QUOTE(Ben @ Aug 15 2007, 04:13 AM) It only uses a single loop. No sharing of tasks between multiple loops or even multiple VIs running in parallel. QUOTE(Ben @ Aug 15 2007, 04:13 AM) Becuase the state transtitions are only established while the code is running, it is impossible to diagram what will happen in what order. I thought all state transitions were established at runtime. The difference is how transparent they are to the developer, right? QUOTE(Ben @ Aug 15 2007, 04:13 AM) States will execute in the oder they are removed from the stack but because states can "preempt" other operation already on the stack, you have to repeatedly check what is on the stack to understand where it is going (possble if the stack is an array, impossible if the stack is in a queue). And then if you decide something bad happened in an earlier state, there is no way to trace it back. Adding in the complexity of preemption and priority scheduling to the architecture already described is chaotic. David

QUOTE(Ben @ Aug 15 2007, 04:01 AM) Unfortunately they did not make this invoke function available for arrays. (Not even in 8.5) Would be a great product suggestion, though. With 8.2, the tabular controls got additional properties for things like 'content rect'. There is nothing like this for arrays, so the code is still ugly. I just looked at my CR code again and remembered that it could be a lot cleaner by just using the 'Master Rect' property -- but that is a scripting property. :thumbdown:

QUOTE(NormKirchner @ Aug 14 2007, 04:53 PM) Don't just give up, run the other way!! It's a hack!! :laugh: QUOTE(NormKirchner @ Aug 14 2007, 04:53 PM) Now the only caveat is that you have to do some mouse/ctrl position magic to determine which # element changed in the array, but you're in luck, this code already exists somewhere on this forum, possibly in the CR. Arrays can indeed be useful at times, otherwise I suppose that I wouldn't have made that CR code that you referred to. So whatever works best for you. David

QUOTE(Ben @ Aug 14 2007, 01:12 PM) Could you show a picture of a block diagram demonstrating such a monstrous construct? QUOTE(Ben @ Aug 14 2007, 01:12 PM) With LV's multi-threading, it seems to me that there is no need to use one of those undocumentable monsters. ... Are the days of the QSM behind us? What would the future be?

QUOTE(orko @ Aug 14 2007, 02:56 PM) I agree. I was thinking about how to explain what you would have to do to accomplish what you want... It is possible, but for the front panel it is not the best construct. So only to reiterate -- you need to choose front panel components that work well for the user and for the GUI code (events, etc.). And you need to choose data constructs behind the scenes (i.e. block diagram) that work well for managing your data and processing it. Arrays of clusters just tend to be problematic for front panels.

QUOTE(yen @ Aug 10 2007, 04:42 PM) Maybe it should be... QUOTE(silmaril @ Aug 13 2007, 06:13 AM) Right, it's not common, but that doesn't mean it has to be bad I'm doing the same with enums in my current project. I am displaying quite a large table to the user. Every time the user clicks on a cell, the appropriate control for this column is set to the last value from the cell, moved into the right place and given the focus. I am doing this for different data types (some are just simple string controls, some are enums). Now I had exactly the same problem: how do I know when the user is finished editing without changing the value? This is exactly the type of scenario I am looking at. I am developing a generic tool to handle tabular controls that contain multiple data types. Surely that is a common UI requirement. QUOTE(silmaril @ Aug 13 2007, 06:13 AM) What we really need are "Got Focus" and "Lost Focus" events for controls! :thumbup: This would be good, but clicking on the current value of a ring doesn't lose the focus. It would be a workaround for clicking elsewhere or tabbing, but I am looking for something that appears more 'built-in' or seamless.

There is no way of currently determining the event of selecting the current value from a ring/enum popup. Either a different event needs to occur stating that the ring is done, or we get a Value Change even when nothing changed. Then you would need to compare the values to check if the value changed or not. At the least you would need a property to check whether the ring selection area is active or not. USE CASE : Consider if you wanted to display a ring dynamically on the front panel for the user to select data from. To subsequently hide this ring one would need to know when the selection is complete. If the selection is to keep the current value, there is no event notifying that the ring selection is done.

QUOTE(i2dx @ Aug 9 2007, 10:12 AM) I did get the Programming palette to be the default open palette. I will look at how I did it and post it. UPDATE: This is how I did it. 1. Pin palette to be always visible. 2. Click on the 'View' button and choose the 'Change Visible Categories' option http://forums.lavag.org/index.php?act=attach&type=post&id=6576 3. Make the categories visible that I want http://forums.lavag.org/index.php?act=attach&type=post&id=6577 4. Move the Programming section where I want it http://forums.lavag.org/index.php?act=attach&type=post&id=6578 5. Open the programming palette and close the other palettes. Hopefully I didn't miss anything

QUOTE(crelf @ Aug 1 2007, 12:19 PM) True, true. Hope NI-Week is going well. Maybe someday I will make it out there.

A CAR has been filed on the issue for further investigation by LabVIEW R&D team under CAR ID #4C2ANAK8

Thank you very much for such a detailed explanation. I'll start digesting it.

QUOTE(yen @ Aug 2 2007, 12:13 PM) Yes, but I don't have a CAR# yet.

QUOTE(Tomi Maila @ Aug 2 2007, 09:22 AM) I lived in Helsinki for three months while I did an exchange program at the Helsinki University of Technology (HUT). It was summer so the weather was beautiful I just loved celebrating Juhannus. Not to mention watching the sun travel nearly horizontally across the sky.

QUOTE(Aristos Queue @ Aug 2 2007, 09:02 AM) Looking back it seems like this could easily have caused a Mouse Leave event in other versions. But I hope that this special case was handled especially. And thus hopefully something broke in 8.2 which means it will be fixed in a future version. Because I see no real use for getting that event for entering a control's popup selection area. In fact, for LV 7.1 at least, if you clicked on a ring and then left the VI front panel completely you didn't get a Mouse Leave event. I assume that what really changed is that when a ring was clicked on, further mouse events went to whatever was showing the popup. Now in 8.2 the events are being routed back to the owning VI. So maybe you just need to filter what events are sent.

QUOTE(Tomi Maila @ Aug 2 2007, 08:40 AM) Well it has been five years since I was living in Finland. And if you didn't all speak so much English over there I might have learned more Finnish

QUOTE(Aristos Queue @ Aug 2 2007, 08:35 AM) The popup is 'part' of the control that is on that VI front panel. No matter how it is implemented it should not state that you left the VI's front panel. This is new behavior with LV 8.2 as well.

QUOTE(Aristos Queue @ Aug 2 2007, 08:29 AM) Doing that right now. Wanted to get some independent verification first.