GregFreeman

I am trying to open shell32.dll with .NET but an exception is being thrown. I'm seeing this type of exception all over when I search google but really not much related to LabVIEW (mostly vb.net, c#.net etc). I have tried loading shell32.dll from system32/shell32.dll and SysWOW64/shell32.dll and both fail. I am running 32 bit LabVIEW on Windows 7 64 bit. I'm guessing it has something to do with that. I am going to try on a coworkers 32 bit computer when I get a chance, but does anyone have suggestions?

Thanks.

Edit: Tried on 32 bit labview on a 32 bit machine and it still fails.

I have a multicolumn listbox where I would like a "right-click" to set the value of the MC listbox to the row that was right-clicked, then a shortcut menu will appear. Depending on the value of the MC listbox (i.e. row clicked) I determine what right-click menu options are available. To do this, I use the mouse down event, and if it's a right click, I set the MC listbox value to the row clicked. Then, the shortcut menu activation event is fired, and in there I use the current value of the MC listbox to enable/disable menu items. My question is this, can I always expect the mouse down event to occur first (it seems it does), or do I need to manage the order in which the events fire. I guess I could also handle all this logic in the mouse down case, inside my case structure, when checking which button was pressed. What I want to make sure I avoid is the shortcut menu activation firing first and having the wrong row selected in the MC listbox which may disable/enable the wrong menu items.

Edit:

After discussing w/ co-workers, I think the answer is yes, because the mouse-down is the event, the shortcut menu activation is the system response to that event. Please let me know if this is wrong.

Thanks for your response. I think I will take the groups approach for each time an exceedance happens because I agree that does make more sense to the end user. Unfortunately it is not exactly as straight forward as just "log when above, don't when not" there are some other conditions like "while exceeding the limit, log x seconds worth of data every x seconds" so there will be time gaps even if the threshold is crossed once and stays above the limit for an extended period of time. I believe I can handle these gaps progammatically with properties, by appending the waveforms in the TDMS file, but writing this time gap and number of samples-per-write as properties. Then when creating a custom viewer, using these properties to split the data back out and put "filler data" of 0's in between, where the gaps were. This keeps the log file smaller, but visually will make sense when displayed to the user.

I have a TDMS file where I would like to log waveform data. But, I am only logging when certain conditions are met. This could result in some condition being met, then the condition going away, then coming back etc. For example, if I want to log when the RPM exceeds a value, I will start on this exceedance. But, maybe RPM drops back below a threshold so I stop logging. Now the RPM comes above the exceedance again, but if I log my waveform to the same channel, it doesn't account for this new t0. Does anyone have any thoughts on work arounds for this? I could make a "timestamp" channel and extrapolate out the timestamps from t0 and dt, but then I need a timestamp channel associated with each DAQ channel. I could have a channel of t0's where a property is the channel it's associated with and the start index of that data from within that channel, but all this is quite in depth. I have also thought about just making a new group or channel for each exceedance, but this could be confusing to the user if using the TDMS viewer. Is there a simpler way?

Edit: it is saying no file selected for upload. I may not be able to attach it from work, unless someone else has a solution for this. If this is the case, I will have to attach it later.

Could someone please save this back? It's a decent amount of files so if not it's not a big deal. I'm just trying to look at it for expansion of my LabVIEW knowledge . Also, I thought there was a board either on this forum or LAVA dedicated solely to saving back versions but I couldn't find it. If someone knows and can point me to it, I'd appreciate it for future reference. Thanks!

In that case, ignore my comments about the "must override" option -> this isn't available in LabVIEW 8.5. As an alternative, I often have my parent VIs return one of two error codes - one for the "you really must implement this VI" error, and one for the "this optional feature was not implemented error". The downside with this approach (when compared to LV 2009) is that you only find out about the missing important VIs at runtime.

Here's a back-saved version of my example.

Shaun

Perfect, thanks!

I've attached a little example of what I was talking about.

LabVIEW does select the appropriate VI, but the raising of an error is used to tell the main application that whatever was requested did not get done because that particlar amp does not support the particular function.

In the attached example, Apmplifier specifies that all child objects must override Init and Power On-Off, ie if they dont have these VIs then everything will be broken (this is a really nice improvement in LV 2009), however, the "Set Volum.vi" is "optional". The base class's version of this VI simply generates an error, so if a child classe does not replace this VI with something else, the error will be generated (if the VI is replaced, then the alternative functionality will be used instead).

Hope this helps!

Shaun

One issue, I'm using 8.5 Sorry, I haven't set up my signature yet.

To work be able to wire your generic "Amplifier.lvclass" wires to the commands of the specific amplifiers, then yes, you will have to create the dynamic dispatch VIs in the parent class.

One thing that I have done in the past for such "not always implemented" functionality, is to have the parent VIs raise an error for "unsupported function" (using whatever custom error code you feel like) - that way, if the specific child amplifier class does not implement a particular command, you will get a known error that can be nicely handled by the rest of your app. If your using LV 2009, this can then be nicely extended using the "must override" checkbox in the class "item settings" property to say that certain functions (such as init, or power on/off) must always be implemented (if those VIs are not replaced then you will actually have broken run arrows).

Thanks for your response. Just one more question.

Do you mean raise an error in the child class? How would you test the input wire type in the parent class? Wouldn't you want LabVIEW to delegate which child method to call and if it gets called then set the error there?

This is the actual project I'm working on and somewhat relates to my last post in this forum. In my event structure, there are broken wires. I understand why but I was wondering the best way to go about fixing this. What my code is doing is reading an ini file and populating an array of amplifier classes (each type of amp has its own class) that inherits from the base class amplifier. I want to be able to take this array of sub classes that all inherit from my base class and wire it up to functions such as operate, standby, reset etc. However, most of those methods are only methods of one specific class type, and don't relate to all classes. Will I still need to make the functions polymorphic (dynamic dispatch) and initially define them in my base class even though they don't relate to all sub classes? This is for the situation of being able to index the array and wire the class elements to different methods.

Sorry that's a bit wordy, hopefully seeing my VI's will help the question make more sense so I've attached them. I'm thinking I will have to put the methods in the base class and make them dynamic dispatch and for the amplifiers that they don't apply, just leave them blank but I wanted to see if there were other options. If clarrification is needed let me know.

As always, any other comments are also appreciated. Thanks.

Looks good to me also. I was using LV 2009.

For me, the array was being filled with empty strings. Did the array populate with the private data strings for you?

For me, the array was being filled with empty strings. Did the array populate with the private data strings for you?

AH rookie mistake. I have to set the string first. Duh.

woooops...second try

I posted this on NI forums but I figured I'd post it here since LAVA as a specific OOP section. \

Just teaching myself some OOP because I want to implement (no pun) it on my next project. However, I can't for the life of me figure out why the attached wont call the child methods.

QUOTE (peteski @ May 22 2009, 04:15 PM)

No worries! Dang... I was 25 when I first started to use LabVIEW, so in one way of looking at it you have a head start on me!

-Pete Liiva

However, back to the most important point...setting a wait for next ms multiple to 5000 ms is not a good way to control how often you take data, as it will cause you a considerable wait time when trying to stop the program . I learned this the hard way in the first program i did when i wanted to take data every 120 seconds lol

QUOTE (peteski @ May 22 2009, 02:38 PM)

Just a little bit of trivia, way back in the dark ages, like before LabVIEW had the "Undo" feature, this is the only way "while loops" worked. I wonder if this example has some old heritage to it?

-Pete Liiva

Haha, the funny thing is I posted this on the NI forums as an example of rube goldberg and got the same response! How could i have known, im only 22 lol.

QUOTE (xShadowDanx @ May 12 2009, 09:39 AM)

Hmm, i tried creating the period control using the Wait vi but still nothing happen. In fact now the Start Button auto run by itself without me even pressing on it.. do i need to put a loop too?

I haven't looked at your VI, I don't have Labview on here. However, using a wait doesn't seem like a good way to do this. If you want to stop your program and you press stop, you may have to wait up to 5 seconds for your program to end. Why not use a elapsed timer.vi and wire the time has elapsed booleanto a case structure. Inside the true case put all your data taking proceedures.

QUOTE (Tim_S @ May 8 2009, 01:46 PM)

I got your code open. I have attached a simple example of how you can take data every 5 seconds. I would say though that there is some bad code in yours. Why do you have error, wired to a not, wired to continue while true? Why not just wire the error status to a stop if true? Rube Goldberg code. Also, how are you stopping your program? Does it just run until there is an error? You should wire a stop control and the error to an OR then wire that result to the stop sign of the while loop. It looks like you are using the abort on the front panel to stop which is a no-no. Anyways, here you go using an xy graph. Little messy but you should get the idea. You can change the 5 constant to a control to change how often the data is taken. If you want to write to a file you would also put that in the true case.

Glad I could spark such a discussion!

QUOTE (labviewnoob @ May 20 2009, 02:20 AM)

Is there any better method for it? any graphical help would be welcomed. many thanks.

In order to be helped in a more detailed way, you will probably need to give more details . Do you want to select a range of data? Do you want to select numbers from a specific column, row, or column and row? Is your array 1D or 2D etc? All these things will help people answer your question.

When you say start/stop/reset do you mean if you stop it its actually like a pause? Where if you hit start again it will start where it left off? Here is an example of using a timer to at least reset. I'm sure you can easily modify it to do the other things you need it to. Maybe I am misunderstanding your question but I think this is the simplest way to do it. If you need an example for a timer that can pause, look up the practice CLD exam for a car wash. Their timer in the solution has the ability to pause. Hope this helps. The left is a screenshot of the timer, the right is your program

Thanks guys.

It was pretty simple and I think I already understood it, I just wanted to double check that I wasn't leaving out some "coding standard" for VISA sessions

In the past few months I have built Labview programs at my university and haven't used shift registers with my VISA wires when taking data in a while loop...the data was collected fine. I was wondering when its necessary to use them for VISA sessions, when/if its OK to sometimes not use them and why. Thanks in advance.