Aristos Queue Posted February 18, 2007 Report Share Posted February 18, 2007 QUOTE(Tomi Maila @ Feb 17 2007, 12:17 PM) It seems that some of these LV Classes related scripting nodes don't work in build applications. I fail therefore to find the parent for my objects at runtime in a build application. Is this by design or is there a bug. Tomi By design. No scripting works outside of the dev environment. You can build scripting into DLLs, but those DLLs will only operate when called within a development environment of LV. Reason for this: There is no compiler in the runtime engine... it is for running, not editing. Quote Link to comment
Tomi Maila Posted February 18, 2007 Report Share Posted February 18, 2007 QUOTE(Aristos Queue @ Feb 17 2007, 09:40 PM) By design. No scripting works outside of the dev environment. You can build scripting into DLLs, but those DLLs will only operate when called within a development environment of LV. Reason for this: There is no compiler in the runtime engine... it is for running, not editing. So there is no general way to test if my object is of certain runtime type or it's decedent in a compiled application. For example if my object is an Integer and I want to test if it's also a Numeric I cannot do this because I have no way to find out if Numeric is an ancestor class of Integer. I'm not looking for a class specific way but a general way. A class specific way can be done using to-more-generic casting but it works only for particular classes and you have to know these classes at compile time. I need to do this matching at runtime. AQ: Does this mean that your second factory pattern does not work in a build application as it relies on scripting. Tomi Quote Link to comment
Aristos Queue Posted February 20, 2007 Report Share Posted February 20, 2007 QUOTE So there is no general way to test if my object is of certain runtime type or it's decedent in a compiled application. To do inheritance testing, use the To More Specific primitive. If it return an error, then you don't inherit from the given type. That does not give you generic runtime type testing (you have "test if this runtime type inherits from this compile time type" but you don't have "test if this runtime type inherits from this runtime type") but it solves most cases. And, yes, it works in the runtime engine.QUOTE Runtime must be aware of the class hierarchy somehow, otherwise I wouldn't be able to unflatten data from a flattened string. How can I access this information? There must be a way. Don't get me started on this topic again. I've ranted enough elsewhere. Basically, I found out late in the release cycle for LV8.2 that *all* the .lvlib reflection API was dependent upon components that only exist in development environment. Writing properties (aka scripting) was always dev-only, and that makes sense. But reading properties? That's generally available for all controls/VIs/etc at runtime. But not libraries. And because classes are types of libraries, we have the same deficiency. No one objected for libraries since they really only provide namespace control and a reflection API is much less useful for them. For classes, however, being only in dev is a major functionality loss. It was too close to release to change when I found out, so I couldn't raise objections, and now it is entrenched. Digging our way out of this is non-trivial. That's a big reason I've been so responsive in this thread -- trying to get as much runtime functionality as possible written in G as a workaround for the missing built-in functionality. Quote Link to comment
Tomi Maila Posted February 20, 2007 Report Share Posted February 20, 2007 QUOTE(Aristos Queue @ Feb 19 2007, 12:51 PM) To do inheritance testing, use the To More Specific primitive. If it return an error, then you don't inherit from the given type. That does not give you generic runtime type testing (you have "test if this runtime type inherits from this compile time type" but you don't have "test if this runtime type inherits from this runtime type") but it solves most cases. And, yes, it works in the runtime engine. Ok. Doesn't solve my case. It seems I've to raise my hands up or try to hack my way into the internals of LabVIEW. AQ, if you are interested in what I'm trying to achieve, I can post it to you as a personal message. I think it's pretty cool a feature but I only get it to work on development system. Tomi Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.