I had an problem regarding design of EVM machine.
Once the button is pressed a vote must be counted. So for that a counter is needed how to create that?
Without knowing more about your project, I'd use a WHILE loop with an EVENT Structure. The Event Structure waits for a Value Change event on the button. On a change of a button, the corresponding value in the shift register is increased by 1 and displayed.
The snippet is missing the initialization of the indicators, since they are updated on the first click, only.
Related
I am currently working on a LabVIEW project and have found myself stuck on how to make a while loop exit when I press the abort (stop) button. For a simple while loop I understand how to do this - but the problem is that this while loop is nested inside of an event structure and I'm guessing that the button cannot be pressed while the loop is executing. Attached here is a picture of part of my code (that contains this specific event case which is causing me problems): To spend a little more time explaining what the problem is - I think the code is doing what I want it to do (namely output a set of commands in a repeated cycle with a wait timer) but I cannot stop the code mid cycle (pressing the abort button with my mouse does nothing - as in the button doesn't show it being pressed and the indicator shows no change, I also can't use any other functionality of my program during the cycle which I'm assuming is related). And I do not want to stop the LabVIEW program from running entirely - just the code inside the while loop pictured above. This is what the front panel is configured too for completeness:
Essentially what I want to happen is the while loop to execute when I press DWG and in the middle of the cycle be able to abort it. Sorry if my code seems a little messy. Additionally, I've tried the same code with a for loop originally (via a conditional terminal so it could stop early) and that didn't work either. Thanks for any help I appreciate it!
Your problem is that inside the event structure, by default the UI is frozen so no UI actions (keyboard/mouse/etc) are processed until you exit that frame.
Option 1. You can right click the Event Structure and select "Edit events handled by this case" dialog and then uncheck the "Lock panel" checkbox -- that will allow the UI to be live while you are in that frame. I do not recommend this solution generally unless you have an extremely simple user interface because it leads to the user being able to change controls without the events behind those controls being processed (not a good UI experience for users). But if the UI is simple enough, that works.
Option 2. You can create a user event that is the code you want inside your While Loop. When the Deg Wait Go button is pressed, use the "Generate User Event" node to trigger that event. Do the same thing in the user event case so that the event re-triggers itself if and only if the Abort button has not been pressed.
Option 3. Create a separate loop OUTSIDE your UI loop that does your processing with some sort of command queue running between the UI loop and that other loop. The other loop moves into various states at the request of the UI loop... it's the one that does nothing until it receives a "go" message and then keeps looping until it receives a "stop" message. You can Google "queued message handler" for extensive details of this solution. This is the most common solution for complex UI requirements, especially useful for separating concerns of the UI code from the execution code.
My event structure in the following part of my VI will work when I start up the program, but never again until I stop and restart. I figure I'm not doing something simple, can someone help?
The event structure is in a while loop. Again, it works once, but not after that...
You have set Enable Beeper Value change action. It will occur once you change the value of the button from the front panel, or change the value trough property node with signaling. Changing value using a local variable or property node value property will not cause Event Handler to register the event.
It seems to me your case structure is fine.
When you press "enable beeper" the event structure should execute the case you have shown and enter the case structure in the True frame.
When you press the button again, the event structure should be executed again this time processing the False frame of the case structure.
(I assume, since you have a local variable, that "enable beeper" is not latched).
If this is what you want to happen but not what's happening the issue could be somewhere else.
Is the Read from Visa function working properly? Could it be waiting for a reply from the hardware?
I have my form with a menu bar and space underneath to display my controls. One of the buttons in my menu bar is suppose to be a print button that prints a graph that's currently in a User Control I display in the form. If the graph was on the form in the print button's eventhandler I could just simply call
graph.printing.print(true)
which isn't going to work in my case since the graph is in the control and not the form.
How do I communicate with a User Control from the containing form and access or pass its variables when needed? I also have a status bar on the bottom of the form which would also need to get updated from the User Control, but I'll be able to deal with that if I got help with just this one part. Please bear in mind, I also have another User Control I'm going to add to the form which will also contain a graph which will need the same treatment as the other graph on the first control when the print button is pressed. I plan on swapping these two out so I have one form displaying one control at a time.
I got this idea from this answer: https://stackoverflow.com/a/18191630/2567273 but after further research I can't find anyone asking about the actual communication process between a form and the control it contains.
I think this answer is close to what I'm looking for, but I think it's leading me down the path to using panels instead of User Controls.
After typing this I noticed the closest answer to my question may be this, but that question has the child raising events and the parent responding while I have the parent raising the event and the parent has to get information from the child.
One way to think about this is Roles. Presumably you built this UserControl to handle the management of the data related to the graphs. As such you can think of them in the Role of a Graphs Specialist . Once you do that, printing them is actually just one more thing it should perhaps do.
The form on the other hand, is not special just because it happens to get receive the command from the user to print. Its role in this might simply to be to know which usercontrol to contact and which method to invoke:
Sub PrintGraphMenuClick....
Select Case something ' determinant as to which UC to contact
Case operation.Foo
ucFoo.PrintGraph
Case operation.Bar
ucBar.PrintGraph
Other menu options like Clear, NewGraph, Save and whatever else there is somewhat the same way. The Form's Role here may be to receive the command from the user and pass it along to the right control, invoking the correct right method and passing the correct parameters - that is not a trivial task.
Of course, rather than a MainMenu, the usercontols could alternatively implement a ContextMenu and even receive those commands directly.
Very often offloading an operation to something else results in so many properties, filenames, streams etc having to be moved from here to there that it becomes burdensome. In this case it is not like the MainForm has some special ability regarding printers that the UserControl cannot handle.
There is only one right solution:
1) Add an event to your user control.
2) Raise the event when the particular "thing" happens in the user control.
3) Attach a handler to the event in Form code.
4) Add code to update the bottom bar in the event handler.
All controls offer some kind of event to indicate that the value has been modified. For example, when you enter a textbox and begin typing with each keystroke there is a TextChanged event. When opening a combobox and selecting a new item in the dropdown, you get a SelectedIndexChanged event.
The trouble is that in many cases the change events signal a series of changes that represent some interim, unfinished state. e.g. When a user is typing his zipcode there's no reason to lookup the city and state or even attempt to validate it until the user finishes typing. When the user has focus on the shipping method combo and presses the up/down keys to navigate through the combo values as he attempts to find the one he wants there is no reason to assume the shipping method has been specified and thus apply it to the invoice. It may make sense to wait until he exits the combobox after paging through the values to signal that a shipping method has been selected. We don't want to be bothered by a series of interim states.
In our shop, we implemented a Finalized event that is only triggered when the user starts making some manual change (as opposed to programmatic changes like setting the zipcode from the DB) and then later finishes up. This Finalized event had to be handled differently for different controls; I'm not aware of any .NET features that would make providing this easier.
The only idea I now have is to try to use something like Rx (Functional Reactive Programming) to accommodate this. Any idea for a simple .NET approach that would facilitate this?
For the zip code textbox, you can use the leave event(occurs when the textbox loses focus), or in the textchanged event you can use an if statement:
if ziptextbox.text.length = 5 then
'Hooray! do stuff here
end if
And you can also just use the leave event for the combobox
The Validating and Validated events work just fine; however, the names were misleading and so it never occurred to me that these were appropriate.
All credit to Hans Passant for his comment that solved this for me. (Hans, will redirect credit to you if you answer.)
I have a custom window to display various objects from the input tree. Once an object is checked on the input tree and displayed in the window, I subscribe to the object's "Changed" event. I am absolutely sure that I did not subscribe to the event more than once. The problem I'm seeing is when I make changes to the object, such as color, the event fires 3 times.
pseudocode:
- Draw a borehole in a custom window<br />
- borehole.Changed += borehole_Changed<br />
- Change the color of the borehole<br />
- See event fire 3 times (I just added debug prints)
Edit:
I have noticed that just opening the settings and clicking "ok" without changing anything causes the 3 events to be fired. So now I assume it actually has nothing to do with changing the color.
I have also tried checking the DomainObjectChangeEventArgs PropertyNames property, but that is always empty.
It looks like the Changed event is being phased out in favor of ColorInfo.ColorChanged, ImageInfo.ImageChanged, etc. In fact, the Changed event is not fired anymore as of 2011 for color changes. Turns out that there were other things underlying that caused the event to fire.
Anyways, to make a long story short, don't use the Changed event.
I can't confirm this behavior, I only get one event - can you please tell us which version you are using? And - are you changing the color via code or via the settings page?
In my case I got a single callback in both cases.
Thanks
I am getting one event also. I am using 2011.1 and the ColorChanged event from the ColorInfo for the Borehole.
In other cases I do see multiple events, but these happen when the data changed triggers changes to other Borehole related data. For example, changing the KB will cause lots of underlying calculations and result in multiple event triggers.