cgiustini

Hi, Lately, I have been experiencing a pretty annoying problem involving exes and file layouts. I built an exe for a project that was calling code that was maintained in a totally different project. The exe I was creating for this project built correctly, but it would never start up correctly in the path where it was built: it would report that it could not find some of the files that made up the external code to my project (Generic File I/O error). It turns that this problem stems from the fact that the filepaths for these files was too large (http://lavag.org/topic/11698-filename-too-long-in-build/). I ended up solving this problem by changing my build directory to somewhere where all filepaths ended up being short enough, but I ended up violating the rules my group had laid out for how we structure our repository. Anyways, I know that other people have run into this problem, and that they found various solutions once they started encountering the problem. Examples of solutions are shortening paths (which was not possible in my case because modifying the layout of external code would have caused a lot of problems), building with the "8.x filepath layout" option, or changing the build directory. In some ways, these are all workarounds and not actual solutions. What I was wondering is if anyone has any ideas/recipes (project layout architecture for instance) that helps totally avoid this problem from the start of the project, not the end. Carlo

I realize that I made some typos here. Now my wrapper could like this --> Now my wrapper could look like this For my wrapper script, the correct code for case if(i==2) is: if(i==2) bark(a)

Hi, I have a question about LabPython. Suppose I am given a Python script that contains class definitions. I want to use LabPython to initialize such objects and manipulate them. Is there a way of achieving object persistence with LabPython? Here was my idea: I could create a wrapper Python script around the script with the class definitions. Let's say my class definition script code/pseudocode looks like this: class d bark_volume = 0 def bark(self) self.bark_volume = self.bark_volume+1 Now my wrapper could like this: i = 0; if(i == 0) import stuff if(i == 1) a = dog if(i==2) bark_volume(a) By changing the input variable i, I can import stuff, initialize an object of type dog, and then call methods on that class. By changing the variable i and making successive calls to the wrapper script from LabPython, I might be able to manipulate the object of type dog from the LabVIEW environment. Does this make any sense? Thanks, Carlo

Yes I can repost it there.

Has anyone come up with a way of creating private messages that can only be sent (with Send my_method.vi) from within VIs of an Actor descendant? The main application would be for creating messages that could only be sent from parallel loops inside an actor's Actor Core.vi to the parent method so that the main actor loop can process the message. For instance, if you only want parallel processes inside the override of Actor Core.vi to be sending their error info back to the loop in the parent method, using a private-scoped message could keep any other VI exterior to the class from accidentally sending error info to the actor.

Hi, I wanted to get people's opinions on the following idea. I am currently writing many lvlibs that we intend to reuse in many different applications we are developing. The interface of the lvlib needs to properly designed in order to avoid any problems down the road: if an interface needs to be redesigned, then many of the applications could have their structure modified. The rework could be extremely painful. If you do as much as remove one input terminal, you need to go through and fix all the places where that terminal was connected to. Now suppose the interface to every single vi becomes the following: typedef cluster in, error in, typedef cluster out, error out. If you remove one terminal in your input cluster, you may have places where you need to remove "Bundle by Names", but you may save yourself some time in places where that terminal did not matter. Has anyone experimented with this? Has this worked/not worked for anyone out there? Thanks, Carlo

That does it. Thanks, Carlo

Hey, I am going to be developing a lot of .lvlibs for reuse by others, and I would like to quickly generate documentation for them. I started programming a tool that recursively looks through a library by using the "Owned Items[]" property and iterating through those in order to find folders, .vis and .ctl. Then using the "VI Documentation VIs", the tool would just output a word document that contains VI icons, terminal lists, and descriptions. Does a similar tool already exist? I would gladly use such a tool if it already does. C