JDave

QUOTE(tcplomp @ Dec 3 2007, 11:52 AM) That's good to hear. Another one question - Has anyone ever registered for events from the containing VI? I want to capture when the Escape Key is pressed, but the XControl doesn't always have focus (so I can't capture it at the XControl level). I haven't been able to successfully register for any events at the VI level. In fact, when I registered for Key Down? on the owning VI in the Exec State Change event (idle->running), it locks the entire UI.

QUOTE(Jo-Jo @ Dec 5 2007, 02:53 PM) Are you programming in LabVIEW? If not, you may be in the wrong place. There is a toolkit for LabVIEW called OpenG that may have accidentally pointed you here.

QUOTE(Yen @ Dec 5 2007, 11:06 AM) So do a search and replace on the \t. The display shows the \ Codes, which is desirable for the display (and necessary to make it work, apparently). As far as a workaround, it seems the easiest route.

QUOTE(BrokenArrow @ Dec 5 2007, 10:22 AM) The code I included in my previous post works with a tab at the end.

QUOTE(BrokenArrow @ Dec 4 2007, 12:56 PM) Have you tried this? Filter the Key Down? event If it is a tab, discard the event If it is a tab, also append the tab character to the end of the string and update the strings value. EDIT: I played around with orko's code a bit. I have no idea why it isn't working. If you click on it, it works. Then you click elsewhere and click on it, and it doesn't work. I think that the SelEnd is counting the \'s, which throws off the indexing. I think part of the problem is that you can't have '\' Codes Display and Update Value while Typing simultaneously.

QUOTE(Justin Goeres @ Dec 4 2007, 08:37 AM) And eventually it will evolve into a culinary masterpiece incorporating the collective wisdom of the human race.

QUOTE(tcplomp @ Dec 3 2007, 11:28 AM) Because I'm a newbie at XControls. Thanks for fixing that. I will give it a good study. David

QUOTE(tcplomp @ Nov 29 2007, 10:59 AM) Here is a barebones XControl example. If you look at the Example VI it shows that the static event causes the boolean to toggle, but the dynamic event does not. I tried to register the event in the Init VI, similar to the Boolean XControl, but it didn't work either. The Boolean XControl registers a User Event, not a UI Event. http://lavag.org/old_files/post-1519-1196708092.zip'>Download File:post-1519-1196708092.zip Example is in LV 8.5

QUOTE(tcplomp @ Nov 29 2007, 10:49 AM) Thanks for the clarification Ton. I misunderstood the problem you were having with the callback VIs. Any experience using other dynamic events? (non User-Events)

Well, I just started peeking into the world of XControls and it does look fun. However, when I tried to use a dynamically registered event -- it just don't work. Has anyone had success with this, or will I just need to restrict my events to static events (since User Events don't work either) ? David

QUOTE(alfa @ Nov 26 2007, 11:24 PM) Ooh Ooh... I have a Secret!! If you turn the and then you get some sweet Alfa, I'm glad you have so much time on your hands this holiday season. Always something to read at work.

QUOTE(sara @ Nov 23 2007, 10:14 AM) If you can demonstrate what you do know how to do, it will be easier to fill in the gaps. Upload some code or a screenshot of what you have tried. You will find you won't get a lot of help until you do so. Not that we are mean, but it is so much easier to help you out if you show what you have tried.

QUOTE(sara @ Nov 23 2007, 10:14 AM) If you can demonstrate what you do know how to do, it will be easier to fill in the gaps. Upload some code or a screenshot of what you have tried. You will find you won't get a lot of help until you do so. Not that we are mean, but it is so much easier to help you out if you show what you have tried.

QUOTE(Justin Goeres @ Nov 22 2007, 07:21 PM) The "draggy-tool" (is it the 'Pan' tool perhaps?) can be invoked by ctrl+shift+drag if you have the auto-tool on.

QUOTE(Cool-LV @ Nov 20 2007, 11:35 PM) I don't know how much you need to differentiate the colors, but thousands of colors will become difficult to easily distinguish. And I agree that a table lookup provides a very nice implementation to your stated problem. David

QUOTE(Cool-LV @ Nov 20 2007, 11:35 PM) I don't know how much you need to differentiate the colors, but thousands of colors will become difficult to easily distinguish. And I agree that a table lookup provides a very nice implementation to your stated problem. David

QUOTE(rkesmodel @ Nov 20 2007, 03:06 PM) That reminds me at least from LV 7.1, you could copy a Front Panel control, then select another control and paste. This replaces the selected control with the clipboard copy. This has the unfortunate side effect of changing the label as well, but I think the rest of the functionality we are talking about is there. This has to be done one at a time. I worked on a http://forums.lavag.org/index.php?showtopic=3040&view=findpost&p=11611' target="_blank">tool to handle this replacing more completely, but I haven't kept it updated for LV 8+. David

QUOTE(rkesmodel @ Nov 20 2007, 03:06 PM) That reminds me at least from LV 7.1, you could copy a Front Panel control, then select another control and paste. This replaces the selected control with the clipboard copy. This has the unfortunate side effect of changing the label as well, but I think the rest of the functionality we are talking about is there. This has to be done one at a time. I worked on a http://forums.lavag.org/index.php?showtopic=3040&view=findpost&p=11611' target="_blank">tool to handle this replacing more completely, but I haven't kept it updated for LV 8+. David

QUOTE(vito @ Nov 13 2007, 06:18 PM) I understand your point here, but I didn't find mixing my events and actions to be beautiful. QUOTE I still find the ability to click in one place and have all my code listed with descriptive headings and able to jump to any using the pop up menu saves me a lot of time. And I find having one place to find all my UI and asynchronous events, as well as another to find all my actions to save me a lot of time. It is very true that with questions of this nature it is very much what appeals to the programmer. QUOTE Anyway the ELCL architecture does not provide a solution since all tasks are delegated to the Consumer Loop and the list is just as mixed. This is true to an extent, but the event is handled up top and the appropriate action is sent down. This provides a clean way to filter events and have a list of actions that is named for what they do -- not what they respond to. QUOTE Does a series of events address your concern "I found that I was trying to pack as much as possible into every event to avoid creating new events"? Other than the fact that I find it abhorrent? I suppose so. But I am not going to create an event for every action that needs to happen. Then I have a mass of events that really aren't events. And my selection list for my Event Structure QUICKLY becomes unwieldy. Not to mention that I can't put artificial separators in the Event Structure. At least with an action structure I can have dummy separators in my enumerated type that help the developer to quickly scan through the list. And it does NOT address the concern of having duplicate code in several events. If several events all require a certain event to be greyed out, then I will put that property node in each and every event. If I later decide that I should make it transparent, I need to find each event and change the code. If I then decide that for some of those events I need to make a different control visible I add that code in. I find it much more readable to send a list of actions down : "Disable CONTROL" and optionally "Show OTHER CONTROL". Then any changes are made to these actions and all the events that call these actions are completely unchanged. Additionally I have a nice list of named actions that each event causes. This is much more readable than parsing the property nodes and code in the event case. I do have to click in the bottom loop to open up any of those actions, but I would have had to click somewhere anyway.

QUOTE(vito @ Nov 13 2007, 04:20 PM) A few quick thoughts. I have tried the ESSM (Event Structure in While Loop) architecture before, for many of the reasons you stated. It worked for me for a while but I found that I didn't like it very much as time went on. Primary reasons are: I found it confusing to differentiate from actual UI interaction and programmatic interaction. I found that I was trying to pack as much as possible into every event to avoid creating new events. I didn't find any easy way to expand it. (I didn't think of chains of User Events or chains of Value Change events) The problem here is that I may duplicate functionality in many different events because I don't have a specific action for it. So it becomes difficult to change the code later on. I also feel that the expansion techniques you describe are more ad hoc patches than an architected design. Don't take that too harshly, it is just my gut feeling and if the ESSM architecture takes off then it will most likely feel more normal. David

QUOTE(Aristos Queue @ Nov 10 2007, 04:52 PM) I will reply here, since I think this applies to icons in general. I very much agree that writing libraries for others to use should follow the convention that only functionality is shown -- how I provide the functionality is not important since you don't need to know. However, for writing my own application I would prefer to have visible reminders of HOW I am doing things. I have developed some conventions of my own to convey if a VI is a Functional Global, or is reentrant, or is only providing a constant, or ... These things are not important for libraries but they are very important to understand how my or someone else's code is working. Especially someone else's code. That gets into the area of icon conventions, and no one likes enforcing conventions on people. But we all like easily readable code. Maybe there is some middle ground in there somewhere. This becomes even more difficult for VIs like Functional Globals that have no inherent quality that the IDE knows about. LabVIEW needs to know it is a Functional Global if it is going to display it differently. I have additionally adopted, therefore, naming conventions to my VIs so that my Icon Maker can parse the file name and automatically add my extra glyphs or different colors, or whatever odd convention I am fond of. And remember that AQ has stated that he wants us to solve this problem, so the ball is in our court. David

QUOTE(EJW @ Nov 9 2007, 12:08 PM) You are trying to place a State Machine architecture into a structure designed to respond to events. This will work, but if nothing else it is more difficult to understand. Having two parallel loops (Event driven Producer-Consumer) and simply placing that state transition logic into the second loop does not seem (to me) like it is more complicated. I have found by experience that saving a little time up front by using a simpler architecture only hurts me more when I try to force additional features in later on. I have never regretted making a VI more robust and flexible than I needed it to be. My :2cents: ...

QUOTE(Justin Goeres @ Nov 9 2007, 09:23 AM) By dynamic events, are you referring to enabling and disabling events using the "Register For Events" node? Or User Events? And when you write "Event Structure in a state machine" I think of the architecture where the Event Structure is located in one of the cases of a State Machine. So after a sequence of states completes, the state machine returns to the IDLE state to handle any new events. I think EJW is talking about an Event Structure in a While loop--nothing else there. But maybe that is what you meant... QUOTE(mross @ Nov 9 2007, 09:54 AM) My favorite application of the Event Strucure is a producer consumer form with queues communicating between the event structure and the non-UI loops. Most of my work with labview is making instruments that need manual control. I am usually automating a variety of DAQ, storage, analysis, and display strictly for my own purposes. What I want in the end is often not apparent when I start. The event driven P-C form is very flexible expandable and predictable. This is a good description of what I am currently hitting everything with. Some additional benefits are having the Event Structure and Actions/States case structure both visible at the same time. This also separates the events from the actions, which provides that expandability. You can always set the cursor to 'Busy' if you want to lock the front panel. David

QUOTE(Justin Goeres @ Nov 8 2007, 02:44 PM) Andyoucanstillreadtheconversationwithouttoomuchdifficultywhichisanamazingthinginandofitself

QUOTE(Norm Kirchner @ Nov 8 2007, 08:14 AM) It also helps if you change the Front Panel Color to the System Panel color. Then the System controls DO match the panel. http://lavag.org/old_files/monthly_11_2007/post-1519-1194539914.gif' target="_blank">