mje

I believe thinking about this problem in the context of Actors (be it the AF proper or in the generic sense) is a red herring. To me it appears to be a traditional problem of static dependencies getting out of control. Not only is this an issue for Actors, but classes of any type, libraries in general, and even more primitive constructs like the lowly typedef or VI.

The only way out of this is to bake some layer of loose coupling into the system: rather than dropping a constant you use mechanism of looking up at run time the type you need.

So I'm not convinced the issue is specific to the command pattern, though since it does invoke objects it does introduce a potential escape of the problem-- abstraction.

As someone who has applications that demand 64-bit architecture, I'm glad to see it adopted beyond Windows even if I'm platform locked for the time being. I can only hope support for these platforms becomes more mainstream.

Also, this:

 

Reviewing and Updating Type Definition Instances

 

In LabVIEW 2013 and earlier, when you apply changes from a type definition to instances of that type definition, LabVIEW may lose or incorrectly preserve the default values for the instances you want to update.

 

In most cases, LabVIEW 2014 automatically preserves the default values of each instance you update from a type definition. When an instance cannot be automatically updated, LabVIEW places the instance in an unresolved state until you manually update using the Review and Update from Type Def. dialog box.

 

You can view the Review and Update from Type Def. dialog box by right-clicking an unresolved instance and selecting Review and Update from Type Def. The Review and Update from Type Def shortcut menu item replaces the Update from Type Def shortcut menu item that appears in LabVIEW 2013 and earlier.

 

That was one of the worst and longest lived bugs in LabVIEW that caused me no end to grief. I won't be able to upgrade for a bit, but this single issue alone makes me think it will be a great patch release as far as code maintenance goes.

I'm curious about this as well because I've not managed to get transparency working that we'll either. I expect that there's no way to get what you want natively. I don't think the picture API understands transparency and I believe the get image functionality uses this API.

I do very little inter-process communication, but I tend to come at it from a different angle when I do. It's not the components (classes) that need to be shared between client and server, it is the interface. It's really a serialization thing.

 

The client may package up a message in class AA which gets serialized through the transport layer. Server gets the data. Maybe it results in another instance of the same AA class being created on the server. Maybe it's the same class but a different version. Maybe the server's deserialization implementation has been updated and creates an entirely different class. The server may as well be a black box-- what happens inside doesn't matter so long as the interface contract is satisfied.

 

For example when I contact lavag.org I don't care what platform the website is running on. All that maters is my interface to the server, in this case the HTTP protocol. I make my GET request and I get my response.

 

I grant you though that if one uses the built-in class serialization then coupling is inevitable. So my only real suggestion to your question on a "way to decouple a message from its sender and receiver" is to settle on a serialization method that doesn't demand this coupling.

I expect arrays of objects have a level of indirection. By this I mean I don't think contiguous address space is required to store each element because the type (and size) of each element can't be pre-determined can change. You would require contiguous space for the array of pointers/handles/references or however LabVIEW handles its indirection, but that should be trivial.

 

So if you have enough memory to store those objects by themselves at the same time, I don't expect that they're in an array to be any different. Also note that I said "expect"-- I don't know for certain if this is how LabVIEW operates but I can't see it being able to be done any other way with dynamic types.

Yeah. The limiting factor is despite the event *sources* being able to be changed dynamically at run time, when it comes to the linkage between the registration refnum and the event structure proper the linkage is static. You can't drop in a new event type at run time and say when that event fires to call some method or event frame.

Compare that with an object approach where dynamic dispatching allows complete abstraction, the lower level loop and transport mechanism doesn't need to know anything about what it is ultimately routing.

I do a lot of this, but oddly enough often shy away from it for UI interactions.

 

Architecturally my frameworks are often designed around this. BaseClass is designed to receive SomeMessage which invokes a dynamic dispatch BaseClass:OnSomeMessage for which child classes may override as desired. In the end the underlying transport layer disappears and largely becomes irrelevant to the component designer-- all that matters is picking off the right level in the hierarchy and implementing the right overrides to hook into the larger application. The framework could be event based, home-baked queues, actors, or voodoo, it doesn't matter much at the component level.

 

I don't find myself using this type of framework for handling too much of the controls in a UI though. Dynamic registration is very powerful, but at the end of the day your dynamic event registration is not extensible. What do I mean by this? If your register for events node is set up to work with ten different events, that's all it will ever do. The next level in the hierarchy can't add another set of events, it needs its own registration.

 

Add to that the venerable front panel is filled with statically defined interface elements means I don't see too much use for objects in this context. Yes, my frameworks may have some level of inheritable functionality that implements an OnCancel method or the like, but at the end of the day they're method calls that are made from a single event structure in a single loop, in a single VI.

 

Don't get me wrong, I use a ton of dynamic events, just not in the inheritable OOP context.

That's a great reference, thank you.

If it turns out I need to manually do it, let's say it shall be pretty low on the list of priorities.

 

I suspect it's a matter handling navigation manually and passing events around. Each embedded sub VI handles navigation across its controls internally, the exception being when reaching the beginning or end of its control list it instead passes the request up to the host VI, which will then delegate the event to the next or previous contained sub VI.

Hi everyone,

 

Is there an easy way to allow controls to be tab-navigated across subpanels? If I have a dialog with SubPanel0 containing ControlA and ControlB, and SubPanel1 containing ControlC and ControlD, I'd like to enforce a circular navigation order of ControlA - ControlB - ControlC - ControlD as one may normally expect.

 

I know I can do it programmatically, it just seems like there should be an easy way to do it without code. Something tells me I can't though.

Yeah, I usually just go for an incrementing integer stored in an LV2 when I need a UID.

On the rare occasion I need a true conforming GUID, I use a small native LabVIEW library to generate strings. I posted that library on lavag a while ago, search for LabVIEW.GUID if you're interested.

Indeed it has, thanks Hooovahh!

 

TeamViewer!

 

In all seriousness, thanks, that was the cause. I forgot I had TeamViewer running in the background. Makes "sense" I suppose since it screws with window frame wizardry.

Something about my quick drop broke yesterday on my main workstation and I can't seem to fix it. It was a sad day for LabVIEW productivity indeed.

 

Now for whatever reason the QD box demands I either double click the correct item or use the enter key once the name is resolved via searching. Neither are particularly convenient as the QD box opens in a fixed location and my left hand isn't exactly within striking distance of the enter key. All my carefully crafted left-hand abbreviations are now worthless. I can no longer just type a few characters and click on the BD where I want the resolved item to appear.

 

The ctrl shortcuts still work though, so there's that I suppose?

 

I'm painfully resorting to the palettes again since I can at least open that menu anywhere I want on the block diagram via a right click.

 

Only reference I've found about this is something about some UltraMon software which doesn't pertain to me.

 

Any ideas?

Thank you!

Have any of you seen a flat or borderless picture control in your travels?

 

I'm using the picture control to render data to the clipboard and trying to get rid of the three pixel control border that gets rendered. Right now I have the border set to transparent which results in a white border around all of my images regardless of their content. If I set it to a color, LabVIEW draws a 3D effect in the border. Ideally I'd like to kill that border entirely, or at the very least have a flat control where I can have the border be a fixed color so it blends into the image content.

 

Back in the day I remember someone here posted a borderless cluster control, so I'm wondering if such an thing exists for picture controls?

Gotcha, I suspected as much.

 

It's more of a potayto-potahto thing. I'd argue the state dependence is a sequence issue and the responsibility of the calling code to manage call order. To each their own.

The offending call would be NI_WebServices.lvlib:PNG Data to LV Image.vi. It converts a byte array to the LabVIEW imagedata.ctl cluster typedef. Without that VI, I think the only built in way around it will be to save the data to disk and use the Read PNG File.vi method. Not sure if this would be too slow for you.

 

Why the memory version of the PNG converter is in a non-base library but the disk version is is beyond me. Ridiculous if you ask me.

The fact that it's on the official roadmap is enough to make my day.

 

/cheers

AQ, that last paragraph confuses me. How does a refnum prevent you from being sure you're read only?

Don't know about growing, depends how you measure it I suppose. A lot of the regulars from a few years back are still here. Some have vanished or have reduced activity but we also have some new faces. All in I still prefer lava to the dark side by a huge margin-- way higher signal to noise in my opinion.

...If I’m sure it doesn’t (and never will), then I consider removing the object output, which is the clearest indication you can have that you aren’t changing the object.

I agree with James. When designing an API I do this. I had often wondered if it was good form until I saw it all over the actor framework. Also helps with dynamic dispatch, it's a clue to the implementing class that the consumer of the API doesn't expect or handle state changes. I tend to however ignore the "rule" for accessors since they're usually just inlined bundle/unbundle operations

As to the original question, I'd wonder why your containing class is storing state data that is calculated by something else that it contains. Couldn't that data be stored in the inner object?

If you're loading VIs dynamically with Open VI Reference, perhaps you need the 0x20 flag?

Refnums are not pointers. The size of their values (four bytes) doesn't depend on architecture.

 

Either way I'm surprised you were even able to declare the original recursive type definition. I'm aware an empty array is not actually recursive, but usually LabVIEW errs on the side of caution and strictly prohibits anything of the sort. I'm inclined to think your ability to declare the type at all may be a bug.

Just curious, how would you implement autoindexing of a string? Would it return a new "char" data type, a u8, either, etc?

 

Well. While we're talking about pipe dreams, I'd have auto-indexing of a string return a (sub)string, thus potentially allowing multi-byte characters and inplaceness.

It takes clusters too? Wow, think of the environmental impact of all those unnecessary loops and cluster primitives I've used. I've been living in decadence.

 

This thread shows some string functions are also very useful for numerics.  I think there should be complete interchangeability.  The surprises should come when the polymorphism does not exist, not when it does.  Besides, there is so much more to searching arrays than finding an exact match, when you unleash the pattern matching normally reserved for strings to numeric arrays amazing things are possible.

 

Agreed. Strings and one dimensional arrays should be far more interchangeable. I have more than once wanted to use the strings pattern matching capabilities on integer arrays for example.