mje

Perhaps I can seed an idea? Somehow getting this tool incorporated into the class browser would be great. Adding polymorphic VIs to a class isn't really that intuitive at the moment.

The MessagePump is saved in LV 8.6, I doubt it can be opened in previous versions.

Oh yes, I realize the two implementations are quite different, I like how you attached your callbacks. I saw your code for VI and event callbacks, and saw an abstraction there that was similar to what I had done via the Callback and related classes I had used so I thought I'd chime in. The real power of your way of doing it is you can use the callbacks to register for events generated outside of LabVIEW that are exposed in .NET or ActiveX objects. Basically, using the callback mechanism you used, LV code can synchronize with virtually any modern Windows code. And for the record, I too am somewhat disappointed at how events haven't evolved with LabVIEW. They are very powerful and I use them all the time, but I also find the exposed interface to often be lacking.

I also like the idea of callbacks. I've previously used an object based implementation to abstract the callback mechanism such that the choice of implementation (notifiers, events, VIs, or anything else) is transparent to a given framework. I've since moved to using such an abstraction almost exclusively now, I rarely use raw notifiers and what not for simple synchronization or cross task communication as the flexibility of a generic callback is much more elegant.

Always been one of my favorite comics, and that one in particular has always made me laugh. You should at least reference the source though.

As candius pointed out, you're looking for nodes, not elements. Sticking with DOM methods, if you iterate over each node and compare its nodeType, you're looking for ones of the NODE_COMMENT (8) variety. If you want more than hints, show us what you have so we have a starting point.

If you can't reach it with a browser, you might have some config issues, as stated. But isn't an HTTP header terminated when you post an empty line, that is a consecutive CRLFCRLF (0x0d0a0d0a) sequence? Perhaps the empty lines in your string constant be tripping you up, or at least explain that error 56.

There are other ways, but the devil is in the details of course, they might not work. Two possibilities: Calculate your state as a function of just one loop counter. If your highest level loop requires 10 iterations (say your data rate and stream command), then you know that whenever i % 10 evaluates to false, you need to issue a channel command prior to the other commands. This can be applied N-levels deep if your logic is sound. Maybe the dimensions of your states aren't well defined. Another possibility is just keeping a series of state stacks. For actions A, B, C, and D, populate 4 stacks (arrays) of settings. When the D stack is empty, you pop an element off the next lower stack C, which in turn re-populates the D stack with a new set of calculations. The D-stack will continue to be operated on until empty again. Eventually, the C stack empties, and the B stack then repopulates the C stack, which also repopulates the D stack...all things eventually unwind when all the stacks are empty. You might even be able to combine the two methods if need be. Of course, there's nothing inherently wrong or non-robust about nested loops either, it's up to you to figure out what's the best given the details of your application.

Awesome, thanks guys. I completely overlooked that TCP palette.

Is there a native way to obtain user credentials from LV? I'm aware of the Application.UserName property, but I'm also looking for any domain the user might be associated with, as well as discovering a computer name and IP.

I completely agree.

QUOTE (NeilA @ Apr 6 2009, 02:14 PM) That path isn't correct, your XML puts the parent UUID element within the http://RMS/ namespace.

Having it only process commands when a configurable key is pressed would be sweet. Hold down ctrl to speak, for example.

Just curious, have you run any metrics to verify that all that time is indeed spent operating on the tree, and not for example, getting the file/folder listing? If that's the OpenG list VI, I suspect it might be slow...there's a double array search happening in it, and if you're using it recursively... Trees are indeed slow in LV, but from my experience, your an order of magnitude or two slower than what I'd expect for that many items. I'd be surprised if the tree is the bottleneck given the times you quote and the fact that you're disabling updates.

/groan

I had a feeling that might be the case, it's a little disappointing Thanks, AQ.

QUOTE (Index Array Function Documentation) The behavior of the function deviates from this documentation when dealing with type definitions, as the attached example shows. It demonstrates a typedef based off an I32, which defines a default value of -1. The function instead returns an element with a value of 0, the default for the I32, not the typedef that's in use. The behavior is the same for both type definitions and strict type definitions. If the behavior is intended, I think the documentation is unclear. Download File:post-11742-1238511295.zip

Thanks, Nitin. I will do so And thanks for having someone look into this!

Saved in 8.2: Download File:post-11742-1238157638.vi

All graphs/charts have two properties exposed via property nodes: Active Plot, and Plot.Visible. Use the active plot to set which plot you're dealing with, then set the visibility of that plot. See the attached VI. Download File:post-11742-1238121732.vi

8.6

I suppose I lied a bit. I have tried, and went so far as trying to initialize. The problem I found though is that the functions exported to the DLL aren't the same as those that you would call from C++ so I was unsure how to manage the lifetime. For example, there's no mysql_library_init(), but there is a mysql_init() (or something similar)...however calling the later crashes LV quite spectacularly. The real turn off for me was much the same. I didn't want to wade through the headers to figure out what a MYSQL struct is, for example.

A framework class I'm working on is exhibiting an annoying problem I'm hoping someone can help track down. The most recent version of the framework can be found at the end of another thread, currently at Post #8. I won't duplicate the item here so as to keep it only in one spot. The problem: After using the class, certain dynamically dispatched VIs won't re-enter edit mode. The VIs have returned, as have any overrides, but are still somehow in run mode. To edit the VI, I must close out the entire project and re-open it. Note that this does not trigger a prompt to save any dirty VIs, nor does it prompt that exiting will abort running VIs (since there are none!). Steps to reproduce: 1) Open MessagePump Examples.lvproj. 2) Within the project explorer, open Examples/1 - Basic Message Pump/Example 1 - Basic Message Pump.vi, execute the VI. 3) Stop the VI by clicking the "Stop" button. 4) Within the project explorer, open MessagePump.lvclass/Public/PostMessage.vi, observe how it remains in run mode despite not running. Also observe that the child class used in the example does not override this method, and as such there are no running overrides of the method. 4) Within the project explorer, open MessagePump.lvclass/Protected/ProcessMessage.vi, observe how it remains in run mode despite not running. In this case, the child class does override the method. Open it at Examples/1 - Basic Message Pump/BasicMessagePump.lvclass/ProcessMessage.vi. Note how it is not running, and is in edit mode. When attempting to switch to edit mode for either of the MessagePump VIs, the following error comes up: Following the steps above, as far as I can tell the error is clearly wrong as no overrides are running. It might take you some time to convince yourself of this as you follow the execution logic of the example. Note MessagePump.lvclass/Public/StartLoop.vi ultimately launches MessageLoop.lvclass/Protected/MessageLoop.vi asynchronously, you should be able to see that this VI does indeed return by use of a break point right before the final error out cluster is written to the indicator, for example. Any ideas why the two VIs are remaining locked? -m

Updated again. Download File:post-11742-1238072753.zip The OpenG Error tool dependency still exists. The class now handles initialization automatically, though the methods are still exposed through the public interface in case a child class needs to have it done manually. Examples have been updated to show this change. The stop mechanism has also changed to allow the signaling thread to optionally retrieve the data context of the consumer loop. This is mainly an update to demonstrate an undesired behavior (possible bug) which I'll post about in another thread.

I've considered it, but never tried...I'm curious as well.