shoneill

Yeah but the setting is made in the STRUCTURE which is not yet executing but still blocks the UI thread. I wish the Event structure had the option to ignore events which are raised before it actually starts executing.

Now that's frustrating behaviour. I ran into this once. Once. Never again.

That works fine. The static events do not share Event Registrations if they are in different structures. It all depends on what the functionality is. If both try to affect the control based on a new Value for example then you have a race condition but otherwise it works fine.

I know this thread has gone in a completely different direction but there IS a subtle exception to the structure behaviour and that is in a sequence structure each frame acts as its own structure meaning that the first X frames can execute before all inputs for other frames are available. Depending on how you look at it ( or expect things to work) it could be a problem. With things like globals, this can end up producing some counterintuitive behaviour. I don't think this is part of your original problem but it HAS caught ME out on the odd occasion.

You can also check out a specific file at a specific revision by using the svn cat command and redirecting into a file: svn cat -r revision URL > Filename I use this to investigate files, detect files marked as modified or conflicting, check out the base file and compare using LVCompare. I use this to detect "false" changes due to RT deploys or conditional disable changes in compiled code and so on. Files which are marked as modified or conflicting but which have no LVCompare changes versus their base reference URL can be reverted without danger and this makes commits much easier to handle when working on RT projects.

Well let's just call it an educated guess. With a lot more "guess" then "educated". But I DO know that each target has specific impelmentations of most FPGA nodes so I could well imagine something like this being handled in the background. Perhaps the XNodes are themselves created by other XNodes depending on the target being chosen. Again, I have NO data leading me to think this, it's just intuition. And guessing, did I mention that already?

They are "abstract" Xnodes which are overridden by the distinct implementation depending ont he hardware target actually being used. Nah, just kidding, I have no idea whatsoever. I've never actually looked at XNodes, but I welcome the discussion.

I've seen bad type propagations all over the place. Whether FPGA Refnums, User Events or stuff like this, incomplete Typechange propagation seems to be a major bugbear in the current LV codebase.

I wonder if the INI setting: RT.DeployInlineSubVIs is already in LV 2012 SP1...... I'm having trouble with deployment to RT involving inlined VIs and I think this might be a patch introduced to help the problem.

^^ This This is why NI needs to keep spending major time in refactoring / bugfixing the current IDE. Stuff like this happens to me all the time. Spend two days trying to find a seemingly impossible behaviour? Oh, never mind, it's just that the IDE wasn't deploying VIs properly to the RT system....... Using an outdated file (correct local, incorrect remote)

Using the strategy pattern for a specific set of functions doesn't havfe to extent into the entire application. It can itself be encapsulated in it's own sub-system. The essence of the strategy pattern doesn't even have to use LVOOP, it can be done with vanilla LabVIEW (but I'm not sure that would make sense). The Strategy pattern is NOT an architecture framework, it's an approach to solving a problem, the scope of which is left up to the programmer.

There are people who may claim that agreeing with me on a LVOOP architecture issue may be a clear indication that you have not fully understood the problem at hand.

Slightly unrelated behaviour: When working on RT, I'd often get bad deploys (but without error) so that the code actually running ont he RT would be different fromt he code the IDE thinks is running on the RT. It seems that the "is running" determination is sometimes a bit less reliable than it should be, especially when dealing with multiple contexts. I think there are some race conditions in the code associated with this aspect of the IDE.

So apparently you get a Virus for your 1000 Dollars?

Sounds like the Strategy Pattern. If you have much shared code between the different modes make an abstract base mode with the read method in there (to be overridden by child classes) and inherit from that for the different modes. Then use that class in your device class which in itself may have a completely different inheritance tree.

I don't really see any other use case for my code at least. I find it useful when I input an object to a generic function, do something to it and then return it. I as the programmer know the object does not change, but LV can sometimes not know this explicitly so here "Preserve Run-Time class" prevents all objects exiting the sub-VI not being automatically cast (edit-time type) to a more generic class.

"Preserve Run-Time Class" will CHANGE the type of your object to match that of the selector (The RUN-TIME type of the object is guaranteed to match) whereas "To more specific" will leave it unchanged or return an error (and when it's successful, the EDIT-TIME type changes to match the selector). If the input types of your "Preserve Run-Time Class" do not match exactlym the output object will be different than the input object. This can be very dangerous if you have any references / resources inititalised in the incoming object. What I don't know is how LV retains / removes certain fields of the objects if a type change is required within a tree of inheritance or whether it just returns a default object (I think it's a default object). I only use "èReserve Run-Time Class" within either DD functiona or functions which accept a static Object input but outputs the same type. By wiring the output to "Preserve Run-Time Class" (and knowing that my code should ALWAYS return the same type as the input) LV then autoadapts the output type of the Sub-VI to match the input, even if the VI connectors are not DD. In your example, you would most definitely use "to more specific" rather than "Preserve run-time class". Shane. If your object is a visitor to NI Week: Lets say the inheritance hierarchy is NI Week Visitor -> NI Week Presenter -> Jeff K Right? Jeff K is a presenter and a visitor, but clearly not all visitors are Jeff K. Using "To more Specific" on a Presenter with "Jeff K" as a selector will either allow you access to the Jeff K functionality on the SAME person or it will fail because the person just looked like him but isn't him and we all get to have a laugh. If you use "Preserve Run-Time Class" and the guy isn't actually Jeff K, the function will actually clone Jeff K for you to make sure that the object returned actually IS Jeff K, but because memories and skills are not cloneable, he's pretty much useless to you int hat state. On the other hand, using "Preserve Run-Time Class" on Jeff K (who's presenting himself as a visitor only) ends up being similar to "To more specific Class" as it doesn't actually change the object. So the function "Preserve Run-Time Class" is to be used only when the TYPE of the object being forced is more important than the data contained within.

Thanks. I found those two links yesterday. I still think that there are certain types of code smell which are typical to LabVIEW which would benefit the community if we could categorise and name them. The immediate follow-on to that is detailing ideas on how to actually refactor them into better code. Please note that I'm not necessarily looking for resources for myself, I just happened to think that it's weird that we don't have any kind of resources in that direction.

I think the way from UML to design pattern is more or less documented but the aspect of refactoring I am missing is when you have inherited a bloody mess of entangled (non-LVOOP) code from someone and getting from THERE to a proper decision of what when and how to refactor it. I'm talking about large code bases which have grown organically over years and comprise several hundred (or even thousands) of VIs. Many of these VIs make (to me) some VERY dubious design choices but the tenmillion dollar question is: Where to start refactoring. There are several aspects to the code which I would love to change but they touch nearly every VI in the hierarchy. Making changes there breaks everything..... Knowing where to start unravelling the ball of twine is sometimes the difference between success and abject failure.

Title of the post: Refactoring : Improving the design of existing code written by Martin Fowler HERE Shane

I have just bought and am slogging through the aforementioned book on refactoring. While it focusses mainly on OOP (not a problem for me) I was interested to read that the author mentioned that the scope of the information is really rather limited due to specific idiosyncracies of particular languages or applications. I immediately thought of LabVIEW (I wonder why that would be) and wondered if there was ever any ideas to approach the idea of refactoring along the same lines of this book. I know we've been receiving lots of helpful information regarding the seminal Gang Of Four book regarding design patterns but I think the missing link for many users who have existing code is how to get from here to there. Due to the different programming paradigm of LabVIEW, refactoring often looks a bit different and we have probably got our own set of spaghetti nightmares. Add to this the aesthetic aspect (readability aspect) and you have a significantly different approach required. While I have my own refactoring experience I was wondering if there are any such standardised approaches to refactoring in LabVIEW?

That's interesting Rolf, any external links to that subject? We make great (as in a lot, not as in good) use of Conditional disable structures in our code at the moment and I find it quite unwieldly even without calculating in bugs and such....

Or just use dumb VIs and a conditional disable......

Hmm, I understand. Hiding the FP doesn't force exiting the Sub-Panel by any chance? I know window visibility has given me many headaches with SubPanels int he past. Things like this will hopefully at some stage in the future perhaps be addressable when the codebase of LabVIEW has been brought up to date.

No. Longer Answer: There was a rather large discussion about this "missing feature" HERE.