Mads

QUOTE (Michael_Aivaliotis @ Mar 13 2008, 08:58 AM) Cool idea, having a GUI gallery. It's often difficult to figure out good designs so inspiration - or stealing some good ideas - is great:-) LabVIEW GUIs have a tendency to look...well - like LabVIEW GUIs, non-standard colors, 3D buttons etc. The examples so far avoid most of that, but there is a big no no in the upper left corner of the windows - a window name that ends with .vi. Aligning and making all of the controls in a group the same size would be another tip, makes it look a bit cleaner. It's always easier to criticize than to make things yourself though:-)

Try logging into the 2003 server by setting remote desktop in consolre mode: You start remote desktop in this mode by running: MSTSC /CONSOLE This will allow you to log into the existing active session. QUOTE(Donald @ Feb 29 2008, 01:12 PM)

I've solved this kind of problem by creating a server application that administrates the access to the port and devices on the port. This "Port Share"-application allows multiple applications to share the same ports (the middleware is the only application that actually use the ports), and it has commands that enables the apps to reserve a port and/or a spesific device (on a multidrop link) if they are in an operation that requires exclusive access for a while (ports are reserved during heavy data transfers, devices are reserved when they are used for tasks that cannot be interrupted by commands from others). In my apps the serial communication is handles by a comhandler-plugin with a que-based interface so all I had to do to switch to the port share system was to replace that comhanler.vi with one that acts as a port-share client instead...(off course to fully use the port/device reserve functions you typically need to implement that at a higher level though). I've thought about releasing this software to the public, however there are some rights-issues to solve for that to happen....The idea is free though:-) QUOTE(Khodarev @ Feb 6 2008, 08:55 PM)

I do not think the reference is closed automagically, there must be some bug somewhere that closes or looses the reference. Is it able to write once and then never again, or? Does the file exist? The shown code never creates it (open, not open or create as action into the open/create/replace file function)...If it is a preexisting file, have you tried generating a new one? If you feed the que twice and probe the reference and error outputs in this logging VI, does the reference ever change and where is the first error? Mads

That's perfect, thanks for the help I had overlooked the add button on the destinations tab. Regards, Mads PS for NI: It would have been great to be able to add it directly in the set destination input on the source tab as well (then I would have found it), but that's a minor issue.

In the app builder of LV8.5 you can add a folder to the source list. I have several folders where I store plug-in VIs and tools (VIs or libraries) so it would be nice if I could add those to the source list and specify that their diagrams should be removed...however even though you actually add a folder it will not add a folder - it will just take the content of that folder and place it in a directory which is limited to be either the support folder, the exe folder or the folder of the caller.... It seems very strange that they could not add a user specified folder option there. So - this seems to mean that I have to do what I used to do - namely to create folders manually, save all the VIs and libs without diagrams manually (although I did make a VI that does this automatically) and then include those folders in the installer. To sum up - is there a more streamlined way to achieve this or should this be a feature request for the next LV? Perhaps the OpenG app builder can help with this? I've not used it yet... Mads

The path does not refer to the correct VI in the sample, however I'm not sure why you insist on using a call by reference node :question: I've updated your sample to a working one. As you will notice I've also added a wait in the subVI loop, you should always have something that prevents the loop from running as fast as possible, otherwise it will use up all the CPU time. On a side note I would also recommend sticking to dialog controls and colors, that will give the users a familiar and professional looking interface, the advantage of using a OS-standard interface should not be underestimated. I also noticed that you are using the place as icon feature for the diagrams...that is the default and it's probably easier to read for beginners, however it takes a lot of space so in the long run it's a good idea to not use that, just a tip The example can easily be expanded to show cool ways to use the run method...you could e.g. make the subVI a template and have as many of them running in parallell as you want. You can also use e.g. a notifier or read the front panel properties in the subVIs to close all windows when the main app window is stopped.

+ If you want the subVI to run in parallell with the main VI you need to run it using the run method like I showed in the previous reply, not a call by reference node.

You have two options - either have a separate loop in the main VI and (statically) call the subVI from there (then only that loop will wait for the SubVI to return, the rest of the main VI will continue to run), OR call the subVI dynamically by opening a reference to it and then use the run method on that reference with the wait until done set to false. To set the inputs of the subVI you use the Set Control Value method: The latter method is great in many situations - I use it to call VI templates (.vit files), then you automatically get a unique instance for each call. A typical use of this is to allow the users to open as many graph windows as he wants... Regards, Mads

Just change the name from LabVIEW to "G" and you are halfway there. The "Lab" makes it sound like a quirky (nonprogrammer) engineering tool.

After 500 ms it is not unreasonable that you've only received 500 bytes, at least if the device has a delay in its response...so if the message is longer you could just wait a bit more prior to checking how many bytes you have received. The buffer length can be adjusted, however it's a good idea to not rely on the buffer. A general receiver (when no termination chars are used) checks the number of bytes in a loop. After each check wait a certain time prior to the next check and if no more data has been received terminate the loop. This "interbyte" wait should at least be longer than the transmission time for a single byte (preferably a bit longer, I typically use 20-50 ms) . It can also be a good idea to have a timeout so that the loop will stop if no reply ever comes and/or if the reply turns out to be continous.... Attached is a VI (SerialIO) for such serial communication (it can be used for read, write and read&write operations). Regards, Mads

If the string is binary and has the MSB first then just wire the read string into a type cast and set the type to an array of integers. The resulting array can be wired directly into a graph terminal. If the string is LSB first then you'll need to swap the bytes prior to conversion, one simple way of doing that would be to just reverse the string, do the type cast and then reverse the resulting array. Make sure you have received an even number of bytes prior to convertion, otherwise the last number may be invalid... If the string is in readable form the conversion depends on whether it is in digital, hex or something else. If you take a subset of the string (two and two bytes at a time) you can use the string to number functions to get the number array for the graph. Regards, Mads

I've just migrated to Vista and LabVIEW 8.5 and was thinking about creating new 48 and 256 pixel, full color icons that Vista supports for my applications, however even though I successfully built an application with such a set of icons something strange happened: If I view the application with a large or very large icon it still shows the LabVIEW icon instead of my customized one. At first I though it was the app builder that lacked the functionality to include the larger icons in the application (the icon editor obviously does), but if I open the built executable with Microangelo Librarian I can see that it does indeed have the custom icons in it - Vista just does not show them for some reason. I've always been annoyed by the fact that NI forces their name and logos into the installers when I really want the development tool to be invisible to the end users (You don't see the installation of your average app show Microsoft logos and ask people where to save the Visual Studio files...), however this will make the LabVIEW logo pop up instead of my app icon whenever the users choose to enlarge the icon view. Have any of you seen this as well and found a way around it (other than a different development tool off course)? Mads Now where is the delete button when you've been a bit too hasty (membership required?)... It turns out this is more of a Vista bug- it refused to update the large icon views properly. The built app kept the default LV icon in the large views, but if I copied the executable to another directory the icons were displayed as they should. Puh! Mads

Having tested this a bit more the bug is still there, however its nature is slightly different than it first appeared: Setting the FP.WinBounds does not show the window, however once the window is diplayed (using the FP.Open porperty) LabVIEW spends time rendering the window based on the FP.WinBounds properties first and THEN renders the window according to the arguments of the Open.FP property. This means that if you opened the panel in a maximized state you will not see the window appear in a maximized state - it will first appear as specified by the WinBounds and then maximize itself - making the opening an ugly two step procedure instead of the proper behaviour seen in LV 7.1.1 (where the user just sees the window pop up in maximized mode). Download File:post-1777-1166111124.vi

In LV 8.2 setting the FP.WinBounds property on a hidden (using the FP.Open invoke node) window makes the window visible. This did not happen in LV 7.1.1. The help file seems to indicate that it should still be possible to set the property in the background like this by hiding the window, however that does not seem to be the case. In LV 7.1.1 you could position the window and then choose to show it e.g. in a maximized state (making the window appear in the defined position whenever the maximization is turned off), I am not sure how this can be achieved in LV 8.2(?). The reason why I want to do this is because setting the runtime position in VI properties -> Window Run-Time position is not an option if you also want the run-time state of the window to be minimized (ideally it should be hidden, but that's not an option).

Make a VI and in its Window Apperance Properties set it to run transparently (100%). Add some code in the VI to call a SubVI that will display its front panel when you click a button, and add a property node that sets the transparency back to 0% once the VI is running. Run the VI and call the SubVI...notice what happens when the front panel of the SubVI opens - the main VI front panel will flash, making the transision ugly. To see the difference, remove the "Window runs transparently" property, and the property node - and run again. Now you get the normal smooth transition. The reason why I wanted to make the main VI transparent on startup is because I wanted it to call a splash screen (instead of the splash screen calling the main VI) and the main should then stay invisible (no startup flash either) until the splash screen closes (it would have been great if you could set a VI to open in a hidden state, why have they not added that to the list of options:-( ). There are ways to work around the problem so its no big deal in this case, however it bugged me...so perhaps its a bug(?):-)

Yes, you will need to write a handler for this using events, however it is not that hard. When the drag is started you get a drag start event ("Drag Starting") that gives you the data that is dragged (not just one row). The data comes as a an array of variants, but you can use variant to data to get what you need. Store that data and if the data is dropped onto a second list you can copy/move the data in code. To ensure the dropped items are from the other listbox scan the "Available Data Names" output from the event for LV_LISTBOX_ITEMS and only perform the drop if you find it... Mads

Quicksort is an example of a function that is naturally made by using recursion...however it is too slow in LV so it is faster (but less elegant) to do it without recursive calls. I needed recursion for the development of this code: http://zone.ni.com/devzone/cda/epd/p/id/12 Mads

I normally use readable files for configurations and the philosophy is that if a user wants to screw up the system he will be able to anyway (if he is not able to read the content of a file he can still change or delete it so encryption is not much help), the only important thing is to prevent him from doing so by accident. If he does delete or edit a file intentionally then that's his fault, not the software (you have to draw a line of responsibility somewhere). You can off course reduce the risk by making the files less accessible and/or make the content look less tempting to edit (adding warnings within the files is an option). If possible the software should also be able to detect and filter out invalid configurations. I store most configurations in the Applications Data folders. The only time I use encryption is when I store information that needs to be secret (like passwords, proprietary parameters etc.). Mads

I see others here are doing their best to be polite and treat your views with respect so let me be more blunt - I think you just don't know what you are talking about. You have obviously no understanding of object orientation but you still insist on debating it (with little or no humility). :headbang: I assume the sewer system analogy is an analogy close to how you view wires in LabVIEW...and you do not understand how we can talk about objects instead of data going through that sewer. The sewer analogy however is way too limited to describe the wire in LabVIEW - LabVIEW already have tonnes of by reference wires which do not fit to that analogy (even though you try your hardest to make it fit). You should in other words be used to think of the wire as something that can send a reference, not always the items (sewage in this case) themselves... It would be interesting to see how your code looks like - what kind of problems you are dealing with and how you solve it. Unless the problems are of a limited nature I am quite sure we could point out lots of places where you are either using the concepts that you are arguing against (and have to do so), or where you could have achieved much better code and applications if you did (it is not always a question of requirement, but a better way of achieving things or better yet - to achieve better results). If not I will be the first to congratulate you on teaching me and probably a lot of others a lesson.

LV is going in two directions Jacemdom - it is trying to make life easier for the non-programmers (Express is an example of this) AND it is trying to become more general and advanced so that it is an alternative to the programmers that want to do more (otherwise the first named users may leave LV as soon as their requirements rise - either to outsource the programming or to learn themselves a language that can do the job). Personally I think NI should worry less about lowering the entry level and more about making LV an alternative to textual programming, but NI is also a hardware manufacturer and so they have other things on their mind as well. Yes, the majority of LV users don't know what a software architect is doing, but you won't find many of those users here Jacemdom. The majority of LAVA users are people that are or want to become power users. OO is an example of something that your non-programming LV user has no need for so the whole discussion about LVOOP will and should be held by "power users", and the majority of those users did not get what they hoped for with LVOOP. To the power user LV is not just a tool - it is G, a language we love to program in and want to see conquer the world! We do not sit on our behinds hoping that NI will someday deliver, we fight for the power of G to grow beyond your "just a tool to solve some measurement/instrumentation/control tasks". We want it to be all it can be!

In the quarrelsome or humourous corner today are we, Jacemdom? It is an object if you choose to view it with an object oriented mind, that's the whole point.

Hehe, parallel universes indeed - wrap your head around that newbies! As bsvingen so elegantly put it, LVOOP makes me feel object disoriented Mads

I understand what you mean Aristos, and it actually made me realise that perhaps the whole problem is that the developers have been too used to object orientation from text based languages when they implemented LVOOP;-) As you say - you have been working in C++ for a decade and are used to even consider integers as objects...and that's perfectly natural because that is what you learn to do when you program in C++, and similar to the "the wire is the variable" concept the by-value implementation of LVOOP may seem natural. To a G programmer an integer is not an object, it is just a variable. Let's say that you want to teach someone what object orientation is and how he should design an object oriented program...how do you do it? One of the core concepts then is that he should try to not think of functions, but real life objects. If he wants to create a car simulator he should think of what kind of objects a car is made of and create the equivalent in code, he would need to make an engine object with its attributes and methods, consisting of smaller objects with their attributes and methods etc. etc....Just as with a real car he will need to construct one if he needs a car. After constructing a car the construction results in a car that he in his mind has a reference to: "my Toyota" and if he wants someone to do anything with his car he tells them to do this and that with "my Toyota". Even though he tells two different people to do something to his Toyota at two different locations they will always work on the same car - they get the reference to a specific car and work on that same car. This is a very simple thing to understand. In a text based language we can write "myToyota" to refer to the object we created, in LV he will wire the reference where he needs it. Now consider the case where this newcomer has created a car class and drags a car object onto the diagram. He may e.g. want two loops to do something with that car so he wires the car to two different places (just like he does after creating a que e.g....he can see an image of the que...people standing in line...in his mind, the wire refers to that que.) - but wait, what are you saying - the branching of the wire created two cars??? Which one is "my Toyota" and what is the second car... What have you done to my Toyota!!!???:-) Off course this is how e.g. a user of GOOP would feel, and it may just be a question of time to get used to the by value concept instead...but I still think he will miss the by-reference possibilities frequently. The by-reference example that ships with LV also indicate that you guys have thought about that.

I must say I support JFM and Jaegen. When LVOOP was first mentioned I hoped it would be a native implementation close to what Endevo made with their GOOP implementation. Using references feels natural when you are dealing with objects, not only in general, but because that's what we have been doing for a long time in LV - we open a reference to a VI, control or other object and use invoke nodes to run methods...Likewise we would like to create our own objects, open a reference to it and get the feeling that that reference points to that object no matter where we might refer to it(!). Except for the really basic users, people already need to learn how to break out of the dataflow paradigm very early when they use LabVIEW. It does not take long before they require more than one loop and a way to share data between them, and voila - the wire does not do the job anymore. The user then typically starts to learn the use of locals and globals and easily gets into trouble. Later he needs to create software that breaks out of the "Virtual Instrument" paradigm because users of modern software are not used to be limited to just a couple of windows- they want to be able to pull up as many trend windows as they would like e.g., not be limited as if they were looking at a physical box...This introduces the need for creating multiple instances of VIs and make them run in parallell. NI continues to sell LabVIEW as something to use in the lab to get the data from DAQ cards on screen, maybe filter them and write them to disk - all in the development environment off course, not a built application. On the other hand LabVIEW is becoming more and more advanced and is used to create stuff that does not belong in a lab, nor can it be described as a virtual instrument (only very simple programs use VIs as VIs, in 99,9% of the cases they are functions). In the case of LVOOP I think the advanced users of LabVIEW hoped that NI would aim to please them and not think too much about new users simply because they would never understand it anyway, nor have much use for it. Ironically it is much easier to understand object orientation if it is by reference....if you really think of it as an object it is very difficult to wrap your head around the fact that you are creating a new instance of the object if you branch a wire...