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...

Great, thanks for the effort! It is good to see that it required the trick of using a button that already had an extra part to replace...if it had been straightforward it would have been more irritating to have missed it... M

The buttons from OpenG Builder can be used as a template to create different system buttons with icons, however how did they make it in the first place? If you go into customization mode and right click on the icon you see that it is an item on its own with different icons for 4 different states...just like a button (as I first implied, although as separate controls), but it is not -because you cannot have a second control within the control, it's something else. Is this just some special button control from NI that was edited for Open G Builder, or can it be made from "scratch"?

Yes, but how do you paste into one of the states without having to replace that state completely (loosing the system adaptive part of it)?

Creating custom buttons has never been a problem - as others have described here its just a matter of importing images to replace the different states of the button...however that replaces the whole button image, what we want to accomplish here is to have a system button "background" that will automatically adjust its appearance to the system it is run on....BUT with an icon on it. I cannot see that anyone has described how to do that without using two buttons - one system and one customized. (If you just go into edit mode on a system control and paste the icon it will become a blind spot. ). It would be great if there was a more elegant way to do it. Mads

The VI Package Manager is off course made in LabVIEW so it is possible... I could be dead wrong, but my guess is that there are two buttons there - one system style to make its color, highlighting etc. work as it should and then a second button that is just the icon...The latter button has had its entire graphics replaced by graphics with transparent edges. Then there is some event handling to make the system button go down together with the icon button when you press it...and vice versa. You can edit a system button and put graphics on top of it, however for some stupid reason the graphics will then act as a blind spot for the button - clicking on it will not give you any response. Mads

The TCP functions run in parallell. We have servers made in LV that handle simultaneous uploads and downloads from hundreds of clients, the communication flows as it should. If there was a need to set the VI to reentrant or it was impossible to allow parallell execution I think NI would either have made it into a subVI you could edit or they would have documented the lacking possibility of parallell execution (if not you would have seen tons of messages discussing it as a bug:-)). Mads

That's great, thanks! Why do they hide all the useful stuff....Scripting is great but not released. Inlining is there but why cannot they make it available as a VI option:-( Mads

The reasons to use sub-VIs have already been covered, however there is a downside to using sub-VIs that should be mentioned. If the code is going to be called thousands of times the overhead in calling a subVI will slow down the execution dramatically so sometimes it is just not a good idea. It would still be much better if you could organize the code in a subVI in the programming development and then flatten the code during compiling, that way you could get neat looking code, reuse etc, but without the speed penalty. I suggested a "flatten when compiled" feature to NI a couple of years ago (could be a subVI option, right click on it and set it to flatten...), however I have not seen any hint of it being implemented. Mads

I was a bit surprised to see this reply because I have always thought LabVIEW executables would terminate immediately if they do not have any front panels open...and when I tried this just now that still seems to be the case, however I am using LV 7.1.1 here so perhaps this works in LV8 or there is some detail I have overlooked? I deactivated all options in the window appearance option window and the first thing I run is the VI close method, and voila - the application does no longer run. Regards, Mads