Francois Normandin

I played with exactly what you describe when the new LV2011 was launched. However, I decided to implement an event callback instead of reading results with the Asynchronous Call function. I used my Dynamic Dispatched method to make sure that all children clones received the event reference to notify the caller of the results. If you need the clones to send different data, make your event type be of a common ancestor to all these types and your caller can deal with each answer in a different way as it sees fit.

That's a very old thread... I'm not sure I remember why I wrote my answer like that. Of course, you're right that it is not a viable solution to use code that could break later. I think I meant that if you make your package "version = 9.0", then you will not be able to install it on other LV versions using VIPM. In essence, you would not be able to update your code to a new version unless you get rid of all this package's VIs. That will prevent it from breaking in a future LabVIEW version because you cannot use it unless you copy it by yourself instead of using VIPM. But if you do so, you cannot blame the original packager for the break in your code. That's what I think I meant by "limit your responsability": by making it strictly a LV9.0 package. For the rest, I kind of suggested that it might never break, so the packager could take a chance and just package it for any future versions... That in itself is not good advice (but that seems to have been what I meant at the time) and Chris suggested a better approach would be to incrementally repackage it each year and deprecate the old package. I agree with that.

Like Jon said. Of course, vip files are not editable using text editor due to checksum, but an opg file certainly would be updatable easily for newer versions... Not that I would do that: it would be faster to simply change the install requirements and repackage it as you suggest.

I'm working on a system to implement biological detection protocols specifically for listeria separation, lysis, trapping, amplification and detection.

The problem comes from your choice of inheritance hierarchy. Inheritance should always be a "Is A?" relationship. In your case here, multiplication is not an addition... so multiplication should not be the child of addition. They could both be children of a parent class named something like "Arithmetic operation". Addition is an arithmetic operation, multiplication is an arithmetic operation. Now it does not mean that you cannot perform an addition in one instance and a multiplication in another, but this should be implemented differently and never forced arbitrarily from the outside. Consider this example where you have a parent class that is a generic 2D geometry where you have stored a collection of points that delimit any geometry (array of points). You could have a child class for a triangle, which would always have 3 points. And you could have another child for rectangles, which would have 4 points. When you call a method that is common to both children, for example "Measure Area", you will be calling the parent method which will dynamically dispatch the appropriate child method depending on the object type that is propagating on your wire. The implementation of the children methods will differ.

Perhaps you can use the call chain to get the caller's reference and give it the focus back once your dialog is loaded. You'd most probably see a flicker in the screen though... Otherwise, there are probably some OS commands that you can call... but it's just a guess.

You can also take a look at BitMan by vugie. It is downloadable with VIPM directly from the LabVIEW Tools Network.

The way you code it is correct. However I only see the described behavior when the column I edit is larger than the control width. I don't think you get what you want unless you set your column widths so that both your columns can be shown completely at the same time. If the horizontal scrolling bar is shown, then it's a good bet that the cells will shift when you edit.

lava_lib_ui_tools_outlookstyle_expansionpack-1.0.3-1.ogp

Check my answer in the other thread. The API presented there has no hidden code, so you might want to particularly look at the Set Private Data VI.

Actually, I might have something for you as well... lava_lib_lvclass_api-2.0.0.15.vip Try this version of LVClass API. It is not for immediate release to the CR because I haven't had time to fully test it myself (especially the "Copy Library" function), but the basic functions are stable. Check the "Private Data" Subpalette.

It is not in the list. You can use the "Create from Reference" method to generate a DVR of generic datatype, then replace the element to the desired datatype. From your previous question on LVCLass, I assume you need a DVR from a class...

Hi Mike, there are methods in the Application Invoke Node, named LVClass.Open & LVClass.Create. Take a look at this palette, it might be useful for you.

Michael A. saw this behavior too in 2006...

Hey Ton, I made a quick fix VI. It should move the boolean text to thye top right corner, outside of the control. Also, it will unlock the boolean text so you can move it. It will correct the whole VistaStyle Buttons hierarchy in the UI Tools folder. Most likely, I will not have time to make the modification to the set and rebuild the package during the week-end... François. CorrectBoolTextPosition.vi (saved for 8.6)

Ton, I haven't seen your post before today. I'll work on it, hopefully this week-end. Hi Prabhakant, you can install the "Control Class add-on" and it gives you an API for doing what you want. There's also a small program you can launch from the Tools menu that gives you an interface for it. There are some videos in the discussion thread.

Set your boolean value to default at False and call the method "Default Values >> Reinitialize All to Default" when you start your program. This method has the benefit of reinitializing all your controls/indicators to their default value with one call.

You guys are more efficient than you think .

I bet that you have SP1 installed... I haven't. Before tackling this issue with a piece of code in CR, I had not used LV2010 since last NI Week. So I guess you guys corrected the bug with the 2010SP1 release. I would normally, but this is part of a framework that the user must simply feed the class type and the rest is done automatically. So in an ideal world, what you propose is pretty much the right thing to do to make sure my paradigm doesn't crash LabVIEW, but here I can't because the user can fork create his own events in parallel, and he might receive the events I send with my framework. I'm refactoring the whole framework. Hopefully it will be even better because I will also circumvent the "bug" misunderstood by-products of an intended by-design behavior of events that cursed Justin at the CLA Summit, which I just read about after listening to Mickael's podcast...

OK, the reason it breaks the code is that I used a technique that could be unsafe if used otherwise. I results from a bug in LV2009, that was not announced (to my knowledge) but that has been corrected in LV2010. I have good reason to believe that the code is safe in LV2009, if you use the Handler as described. However, I cannot garantee that it will not crash as shown in this thread. I've posted an example over there, derived from AQ's explanations, as to how it can easily lead to stop LabVIEW (or crash it).

The reasoning makes sense to me now. Thanks for clearing that out. I put up an example which I think shows how I used it (safely) and how it can be used as you describe and crash LabVIEW. Basically, if I index the array of event refnums, I'll always propagate the data as a "Parent" and never encounter the situation above. However, if I fork the child event and use the arrayed one to transmit the data, then I can cause LabVIEW to stop. Obviously, I'll have to find another way do achieve what I want. The potential is too great for the work-around you've suggested to be implemented in shared code. Test Event 2009.vi

Something fundamental seems to have changed between LV2009 & 2010 about Events Refnums and OOP. This arises from investigating why my code breaks down in LV2010 (LVOOP Event Handler in code repository). In LV2009, it used to be possible to make an array of events where the event refnum of child classes could be carried on the wire of the parent class event refnum. This has changed in LV2010 as it is no longer possible. Digging a little on this issue, I found out that the "equals" primitive has also changed behavior between versions. It seems that if the datatypes can be arrayed, it should also be allowed to compare them, right?. Granted, it should still return "false" if the refnums are not pointing to the same objects, but why the broken wire in 2009? This behavior has been corrected in 2010 so it seems that LV recognized that these are of the same type (or at least in a parent/child perspective). So why would it be impossible to make an array to these? At least, we can still pass a child object on the parent event refnum... and not a parent object on a child event refnum (consistent). Anyone can confirm that this is a bug and not expected behavior? And obviously, one version has a bug... which one? Both?

Can we know who the judges are? aka Who are we to bribe to get our designs some chances of winning against Vugie this year?

Hi Charles, I had missed your post. I'll have a look at this. thanks for reporting.

Great John! Woot.