jgcode

While I understand your point on the correct terminology for the masses, IMHO if the build was failing due to errors when porting between PCs then it has become corrupted. The reason wasn't clear originally and was very frustrating. Once I understood the issue, I was able to solve it by dragging the top level to the desktop and the build compiled without errors. Unfortuneatly, our Source Tree is already well defined, so I can't so this, and I state this again, I can see this being a huge PITA. Whilst I love the change that everything is packed inside of the exe, spending an additional 68 characters to define this file: LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb from LV8.x to LV9.0 when there already is a known limitation of characters is just fixing one problem but adding to another. As for 8.3 filenames it seems NI prefers to promote descriptive files names

The I32 is the current value of the listbox - it is its datatype. E.g. if the 3rd row is selected then the listbox = 2 (as LabVIEW counts from zero). So if you write 5 to a listbox indicator - the listbox will highlight the 6th row.

Answers posted by Gmart in original topic:

This is great news wrt to the build. Internally LabVIEW does not have the same restrictions as e.g. Windows OS. So whilst the build process may become corrupted, once the EXE is build and if it gets moved LabVIEW can handle the long path names. Cool Are you kidding me! No more files outside the EXE, all those class methods hidden, - I am never going back...never I tell you.... But seriously, the build process failing all the time with long files names is starting to annoy me. And thats just from evaluation. I am really worried when if comes to out Source Tree too, if it going to be quite deep already. I can see this being a huge PITA.

Seems in LabVIEW 2009 VIs will not be remove due to constant folding. E.g. this VI will be included in a 2009 build, it was not in 8.6.1

As always thanks for replying Gmart What I am trying to establish is - is it just the build were long file paths may be a problem? And if it passes the build the exe will always be fine? Or could a situation arise that if LabVIEW tries to resolve a path in an executable (depending on where it is in a folder hierarchy) it could be corrupt due to the limitation of characters in the Windows OS?

[Cross Posted to NI] I made a post in this topic regarding build errors in LabVIEW 2009. After thinking about it a bit more I thought it may be worth a topic. I had some code that worked fine on my home PC, when I moved it to work, the exe would not build due to errors. The errors coming back weren't that good at explaining the problem Until I got this one: Look at the path in the error: C:\Users\Developer2\Desktop\User Group Meeting\LabVIEW 2009 new features\code\02 intermediate\01 build specifications\build executable file paths\dist\application 9.0\my application.exe\LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb That path is referring to a VI inside my executable! This may be a bigger issue that I first thought So my question is: If a have a path inside my build that would be relative to the executable and LabVIEW needs to resolve it, could that process fail depending on where the exe sits in a folder hierarchy? I guess this could have happened before? but it would be more likely now due longer paths!

I am getting this annoying one. Another project with the same VI builds ok! <edit> B*st*rd Seems it was to do with looong file paths - not that the above told me that This error info did tho: Problem sol-ved. I am wondering if this has anything to do with the new way exe's get built? Look at the path in the error: C:\Users\Developer2\Desktop\User Group Meeting\LabVIEW 2009 new features\code\02 intermediate\01 build specifications\build executable file paths\dist\application 9.0\my application.exe\LabVIEW 2009\vi.lib\addons\_ICON Library\String\_icon_lib_string.llb That path is referring to a VI inside my executable! This may be a bigger issue that I first thought

It should be noted that the DSC allows this.

This is what I was referring to in my post. Certain functions do not operate in the Run Time Environment. Therefore you can still create an EXE but you need to use Development Environment (LabVIEW IDE) to do the work. E.g. Creating/editing a MNU file. The Agent VI does just that.

Hi unCLAD A work around for this would be to build you VI into and EXE so you have a nice GUI for distribution as you are doing, but when you want to do the actually work of editing the menu file, you will need to call an instance of LabVIEW and run the working VIs in the development environment. This will get around having no support for those functions in the run time engine. Other products do this e.g. VIPM, Sciware GOOP Wizard etc... Some people call the working VIs Agent VIs and the link might be a good example for you to check out.

Hi Daklu I have been playing with LVOOP and DVR also! It is very cool stuff. I had a look at your post as it is very interesting. I think removing the references to investigate the problem may help to solve the issue. Below is what I have come up with. Parent cannot downcast to Child as Parent cannot run extended Child methods (Child can always run all Parent Methods) so you get a broken run arrow and that makes sense, any other casting will generate a run time error (see attached png top). When you use the Preserve Run Time Class function I don't think you are getting a new parent, I think you are getting a new child: When the error occurs, all data on the wire is lost and a new child is created. You can then do what you like with the child (see attached png middle). I think the references may be hiding all this in the example you posted as you can have a parent reference pointing to a child object (see attached png bottom). Therefore I do not think it is a bug either way? Would you agree or am I totally off!

Feature for sure. Stops people from double posting.

They have there place in LabVIEW I guess. For the stuff I do I rarely use them. Except for the File Dialog Express VI, I always use that.

Come-on, you can't expect me to be up on inside VI Engineering jokes! I did think it was weird - I thought maybe the term was lost in translation form over here to there!

I am pretty sure VIPM would do something like this, with their VIPM File Handler.exe You may like to ask on their forums for info too?

I was thinking PITA was some technical software engineering term, but I quickly realised you mean pass in the *ss. I did not know a data copy is made with a SEQ on a read! Thanks for the info.

Great point! I was not stating an opinion wither way, but I do understand its not going to hold 100% of the time - obviously with unique features (e.g. dynamic dispatching, and by value approach) and consequently a unique implementation - that are different from other languages (namely C++ and JAVA). I also guess thats why we have UML so that we can create objects in a universal language, abstracting the implementation (of language). But most of the previous vocab of LVOOP would have been out of the communities' control. I guess with the Ideas Exchange we now get more of an input (if anyone is listening )

Hi Mark I think this might have changed! After all NI sells Touch Panel Controllers with XPe on it (albeit re badged) - we use them for our applications I did inquire a while ago about running DSC from XPe which wasn't offically supported either but should have worked. However I just found this: http://zone.ni.com/devzone/cda/epd/p/id/5956 I am glad I went looking for this and found this out!

Close.. but no cigar

I am for one am *proud* that LabVIEW has native object references! And I don't think anyone is asking to complicate things more (e.g GHEER-MLB) We are just asking for a (as in one) defining, LabVIEW universal term I don't see the point in having a bunch of names to describe the one thing, or people creating there own (e.g. NLCs) That IMO, will lead to confusion in the long run. The fact is LVOOP with DVRs are in LabVIEW which means they are by definition native. If using native helps distinguish from other flavours of object references (Endevo, Sciware, dqGOOP, SEQ, homemade etc..) then, that will just lead to clarification. But thats should be up to the authors and/or the LabVIEW community to decide. Which was the motivation behind creating the topic (that I was interested in what people have to say) And well if its good enough for the authors to describe them like this...and the community agrees, than who am I to argue? There is also a great section on the vocabulary in the LabVIEW Object-Oriented Programming: The Decisions Behind the Design - What considerations were given to vocabulary choice? - if people haven't read it, its a great read. LabVIEW is not C++ or JAVA, while it is nice that there is transparancy across languages, it will never be 100%, and needs not be, as LabVIEW will do things its own way - which makes it a unique language - and thats why I love to use it.

Ahhh... But LabVIEW isn't just any other programming language! And it's (native) implementation of OOP is very unique (thanks AQ ) Should we use standard terms of other languages? I have seen arguments for this, and against this, on the forums Does it hinder or help people learn, who may have or may not have other programming experience??? But I tend to agree - the term object reference sounds clear and concise. Great point on LVOOP-DVR vs LVOOP-SEQ !! I am thinking that LVOOP-DVR is the more native approach, as I can see DVR being the future of byRef OOP in LabVIEW, and as such warrents the term native object references IMO. What do others think?

I see the new Advanced Courses are out! http://sine.ni.com/nips/cds/view/p/lang/en/nid/207398 http://sine.ni.com/nips/cds/view/p/lang/en/nid/202648 Well done to you and Scott. Dude, Kudos for that. "Dude, why did you just voop my girlfriend?"

Hi Jim I gave it a go using Jing and it worked fine. http://www.screencast.com/users/jgcode/folders/Jing/media/bac74cd6-7641-4e97-9586-dc7a18df2658 Do you have Jing to try?

Nice one! What are you doing write now? I am trying out these Community Scope class with X-controls, are you ?