mje

Brilliant, thanks Ton, I completely forgot about that filter event. Works like a charm.

Is there a way to display a menu without associating it to a VI's menu bar or to a context menu of a control/panel? Basically I want to create a pull down button, which when clicked shows a menu hierarchy. Currently I have it set to a context menu for the button and it's perfectly functional, but for usability sake it should really be fired from a normal button press...not every user goes around checking every control for a context menu. Note I know how to handle this by breaking out calls to the OS, I'm just wondering if there's a native LV way of doing it.

Is there a way to display a menu without associating it to a VI's menu bar or to a context menu of a control/panel? Basically I want to create a pull down button, which when clicked shows a menu hierarchy. Currently I have it set to a context menu for the button and it's perfectly functional, but for usability sake it should really be fired from a normal button press...not every user goes around checking every control for a context menu. Note I know how to handle this by breaking out calls to the OS, I'm just wondering if there's a native LV way of doing it.

I think there will be a place for CUDA for quite some time. There are applications where the cost of an NVidia card, be it a $100 graphics card or a $10000 Tesla are literally, a drop in the bucket when the cost of the mated hardware + software is considered. The fact that more general-purpose GPUs from other manufacturers are on the horizon is nice, but solutions already exist today fron NVidia, ignoring that solution when it's available is not really a good idea in some cases. Having an open specification would be ideal, as in it would allow a programmer to detach the program logic from an implementation. However as it currently stands, there is only one implementation, so I see no loss in adopting CUDA. I have no doubt though, that things will be different in a few years. Alas, my BBCode-fu is weak, I'm not sure how to embed this, so I'll link:

My home system's backups are managed by a batch file with robocopy calls as well: for Vista that is an entire solution based exclusively on the tools provided by the OS. You can add in scheduling if desired, but I don't since I keep the backup disconnected from the system. Works wonderfully, and is even network-friendly should my ISP decide to ever stop sucking. My backups are intended to prevent hard disk failures only: they're all stored at home, so any disaster would leave me out of luck. I can't say I believe any of this fireproof nonsense. In a fire, a disk will get really hot. Put it in a fireproof safe and it might not burn, but I don't see how it can be kept cool enough to maintain data integrity.

Putting the breakpoint in the assertion VI will work, but as Yair pointed out, will cause execution to halt in the VI, when I'm more interested in halting within the calling VI and highlight the call to the assertion so the offending code can be seen. I'm still undecided if I even want to use such a VI, I'm trying to design it only for consistency with traditional debugging tools, and historically I'm against debugging assertions at all: if a condition is important enough that it warrants an assertion, use a full error test and breakpoints as needed. However I realize that it's really a design philosophy and some people like them.

I'm in the process of designing a debugging library...still at the stage of throwing ideas around. One thing that I can't decide how best to implement is an assertion VI. The behavior I'd like is that if an assertion fails, I'd like LV to break execution and highlight the call to the VI on the diagram of whatever called it (kind of similar to the automatic error handling bit LV does). One way to do it would be to have an error output I suppose, that by convention shouldn't be wired, but that relies on the calling VI to have error handling enabled. Is there a way to programmatically suspend execution and highlight the VI call? -michael

I've been interested in this since it came out, but have yet to find a case where it would be useful to me so haven't played with it yet. I suspect that since a lot of LabVIEW usage is instrument control and communication, that the applications would be few and far between. That doesn't mean it wouldn't be fun to try it out though! I also worry how difficult it would be to work around the by-value nature of LabVIEW such that data copying and memory re-allocation doesn't destroy any gains you get from the parallelism of CUDA: as with all things CUDA, benefits of implementing it would be very case specific.

You can use any symbols you wish in the conditional disable structure, and you define them at the project level. See examples\general\disable structures\Conditional Disable Structure.lvproj for more info. However, you can't define them for a specific build, unfortunately. (Note an error in the screenshots, they may not work due to case sensitivity, but it gets the point across.) Combine this with the Application.Kind property and you can usually sort out what you need for target/debugging needs. I share Ton's wish though that the symbols could be defined on a per-build basis.

Or for that matter, allow mice with h-scroll to work.

QUOTE (Ton @ Nov 12 2008, 05:20 PM) I've lost track of the weird behaviors I see when editing XControls, they seem rather random, I have no idea what decides to trigger them. I've pretty much adopted the philosophy of edit my XControl, close all VIs, restart LabVIEW, wave a dead chicken over the computer, and hope stuff works. There's some flaky stuff going on with XControls, and I just don't get it. Sometimes XControl objects are kept in memory even after everything has been closed. Even a "Save All" command from the XControl explorer window won't do it. I can close all the VIs I'm editing, all the VIs that use the XControl...hell, I can close everything LV related and be staring at the Getting Started window with no prompts to save these mysteriously changed VIs. Then when I shut down LV by closing the Getting Started window, whammo, I get asked to save a dozen VIs from my XControl that shouldn't be open anymore...but somehow are? I'll be damned if I can reproduce this behavior but I've seen it a few times. Other strange behavior I noticed while making this proof. Initially I named the event ValueChangedEvent. Fine fine, then I go ahead and change it to something more descriptive. But for the life of me, I can't get the event name to change. Despite all my efforts to track down where I might be still setting the name to "ValueChangedEvent", I can't find it, yet is somehow appears in my code. Also, here's one for you: why does a double need to be coerced to a double? I think I just ought to give up for the night, this isn't making any sense. And honest, I'm sober. Attached is the proof VI that I fiddled around with, no documentation, but there's really not much to it... The coercion dot can be found in the facade, and the mystery event name can be seen in the test VI. Download File:post-11742-1226538104.zip

I have an XControl that I'd like the owning VI to be able to respond to events fired from that XControl. My current solution uses dynamic events: 1) Define the state control to hold event references for each event. 2) During initialization, but after deserialization, create the events dynamically and save the references in the state information. 3) The XControl defines read only properties that expose the event references. 4) In the facade, fire the events as needed. 5) Destroy the events during uninit. When a VI needs an event, it obtains the reference from a property node of the XControl, registers for the event, blocks on an event loop, and eventually unregisters for the event. This appears to works fine in my proof of concept test. Question is though, is there a way to statically define these events? That is, when you work with "normal" controls, you can select static events from a list when defining a new event case, I'd like my events to appear along side the NI static ones (such as Value Change, Mouse Up, etc) when my XControl is selected from a VIs list of controls and bypass the whole dynamic registration bit. -michael

I'm not sure the details of how the CINs work as far as setting up the function call stack, but you're node is not set up properly, is it possible the stack isn't being properly defined leading to undefined behavior? lpEventAttributes - Long pointer (32 bit) to a structure, in all likelyhood should be a NULL (0) U32 value or a LV call. You're passing a null string, I'm not sure if LV will simply pass a null pointer which would work, or a pointer to a null string, at which point it's anyone's guess as two what happens. In either case, the sturct is prototyped as {DWORD, LPVOID, BOOL}, so a string pointer will in all likely hood cause all hell to break loose. bManualReset - A BOOL is simply typedefed as a U32 in the C/C++ land, the use of a U8 might not work here. bInitialState - Ditto lpName - Seems right, long pointer to a string. You're right though, a return value of 0 (NULL) means the function did not work. Edit: A call to GetLastError might also help figure out what went wrong.

Programming > Application Control VIs and Functions > Quit LabVIEW will do the trick. Note this can lead to annoying behavior while in development mode, so I usually do something like this:

QUOTE (normandinf @ Oct 28 2008, 08:09 PM) Great, thanks! Whether this is a bug or not is hard to say, it might be working as intended, though it's definitely not working as I would expect. I'd hazard a guess most people would think similarly.

Noob question here (as far as XControls go)... When I plop my XControl down in a VI, it somehow gets an ugly 3D frame, which isn't part of the control. My guess is it's part of the container object that hosts the control? Is there a way to get rid of this eyesore?

The "best" filter to use often involves a solid understanding of both your signal and noise source(s), it's fairly large topic in analytical science. Median filters are a very powerful swiss army knife type of filter, and produce excellent results in many situations. A properly set low-pass filter can often do wonders to data where noise is of much higher frequency than your signal, as can a properly constructed convolution filter. I believe all of these options are available to "Full" versions of LabVIEW, though I can't say for sure in your case, I skipped the 7.X generation.

Wrapping the method should work, thanks for the advice all.

I'm trying to reinvent a framework using GOOP, and I've hit a brick wall. I have a member VI that needs to be dynamically dispatched. The caveat is I'd like to call said method asynchronously (not waiting for it to return). Now I see a few problems with this given my knowledge of how dynamic dispatches and VI server work, but the first one is the most general. How do you invoke a dynamically dispatched VI asynchronously? I've tried my usual way (read: only way of which I'm aware) of opening a VI reference, setting a control value, and invoking it: I expected an error here, and sure enough, LabVIEW doesn't disappoint: Error 1000 occurred at Invoke Node in Test.vi Possible reason(s): LabVIEW: The VI is not in a state compatible with this operation. Method Name: Run VI VI Path: C:\Users\michael\Desktop\Asychronous Dynamic Dispatch\Base\Foo.vi Now I expected an error to arise from the polymorphic nature of object wires...the whole idea of the dispatch is to determine which VI of a given interface to invoke at runtime, and I'm handing LV a reference to a specific implementation and asking it to do its thing. Don't know if that's related to the error at hand, but in the end it didn't surprise me. And this is as far as I've gotten...I keep coming back to the same problem of being unable to define which method is going to be called at design time, yet VI Server requiring a specific reference. Anyone know a way to deal with this? Regards, -Michael

The Programming > Cluster, Class & Variant palette has the function you're looking for. It's small, and I've overlooked it myself before.

Ah, I'm mistaken then. Thanks for the info. I'll have to look more into the virtualization, I think I made a few poor assumptions.

Keep in mind that even under UAC in Vista, you will be able to get at config files located in your your program directory, however the file will be mirrored to a user-specific directory (I forget where, too time pressed to look), so you won't actually be writing to the file you think you are. This will be completely transparent to your program, and not noticeable in a one user environment, but can bring up odd results if you expect changes made to be global for all users since you're actually reading/writing a user specific copy of the config file. I think one of the above linked documents went over that, it's a backwards compatibility thing MS implemented to keep a lot of older apps from blowing up on Vista. Generally, settings should not be kept in program directories. If you need to make global config changes, I think you can write to the application data folder (%ALLUSERSPROFILE%) without special permissions, by default I believe all users have permission to that folder on Vista systems.

The lack of break/continue statements is a big difference. Easily worked around by using case structures, but I've missed them often enough to wish there was some way of having the constructs in a graphical language.

LabVIEW has handled paths/permissions rather poorly in the past in my opinion. I first stepped on this some time ago working on Linux. Note the following article: http://zone.ni.com/devzone/cda/tut/p/id/7005 The answer to avoiding admin escalation is of course to not put data in system directories. The problem is LabVIEW doesn't really have a good way to determine relevant system directories. It can't handle environment variables, so for example, the path "%APPDATA%\MyApp\Fee.txt" fails to resolve, which is one of serveral places an application might legitimately store it's data without UAC getting in the way on Vista. Anyways, I don't believe there is an implemented universal solution to this problem yet. There are of course ways of doing it with a little work. As the article mentions, on Windows platforms SHGetFolderPath (replaced by SHGetKnownFolderPath on Vista or newer, but the legacy function will still work) will resolve paths for you, and FSFindFolder will on a Mac. Linux is more of a mess, there are only conventions to follow, no standard APIs to query.

QUOTE (p.gabor @ Oct 3 2008, 10:03 AM) Having the task as a Dialog VI is probably the easiest way of doing it, as pdc mentioned. When the task is done, the dialog will close and all's said and done. There are other ways though. Maybe you want your task to be run outside of the UI thread, maybe it's asynchronous with respect to the rest of your code, or maybe there's the possibility of multiple tasks but you only want one dialog? In situations like that I usually use one of the synchronization objects (a dynamic event/occurrence/notifier/queue), the VI that spawns the worker task creates the event/whatever, and feeds it to both the dialog and the worker task. When the worker task is done, it signals the event, to which the dialog responds and closes. Just be careful not to create a race condition where it's possible for the worker thread to signal the sync object before the dialog blocks. Which object to use really depends on what you want to do, is a simple signal all you need or do you need to send data with the signal? Do you need to respond to multiple signals?