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

It looks very useful. It would be nice if the open VI was able to automatically create a new database if the path it is given does not exist (you could have a create if it not exists input).

That would be a great feature, and it should have been available. I sent in a suggestion to NI a long time ago to at least stop including the cluster frame in the tab navigation list, for the user of an application built in LV there is never, ever, a reson to highlight what is essensially a programmer's tool. As far as the GUI goes the cluster should not even exist.

Well that's the thing you see - you can (obviously) and you should be able to (off course, it's 2005 after all!). It might be there in LV7 as well. I tried recreating the problem in 7.1.1 and could not get it to happen, maybe it is possible to get the same problem there, but at least it was more difficult...;-) No matter what angle you see it from it is still a bug. I've made the same mistake myself when doing rescaling by code, if you use the original size of the controls and the front panel as fixed references to calculate your scaling factor you can avoid the problem.

Controls are scaled "live" in LV8, they do not wait until you have released the window handle (the grab handle is not there anymore by the way...consistent with the OS so that's good). The algorithm behind seems to have a bug though...just widen the attached VI front panel and you'll see that the controls will expand too much to the right and move outside the visible front panel...This did not happen in LV7.1. Download File:post-1777-1130421408.vi

Followup: The INI keys are the same in LV8 and the bug also applies to the development environment. If you change the font options the menus and the _ prefix will no longer work properly.

Found it! The bug occurs if you override the app and system font in the application INI file. Just put appFont=""Tahoma" 13" systemFont=""Tahoma" 13" in the INI file and you will see the menus garble up in the built application. I have not yet looked to see if these keys have changed, been replaced or removed from LV8(?), it is still a bug in my eyes but perhaps just a backwards compatibility bug...(?) I have attached an example. Removing the last two keys in the .ini file will as you can see remove the problem. Download File:post-1777-1129978050.zip

This actually seems to be two bugs: One is the fact that _ prefixes are interpreted incorrectly and secondly there is no separation between menu items, they are piled together regardless of the use of _ prefixes...Ugly one! Makes menus in built applications useless unless you only have one menu...

Downloaded and activated LV8 and converted one of our projects from 7.1.1. A bit of a struggle to get all the dynamically linked VIs to refer to the right sub-VIs now that it supports "name spaces", and it seems a bit strange to add VIs directly from disk instead of selecting them from the project, HOWEVER... I came across something that looks like a bug, namely how built applications handle top level menu items that have a _ prefix in their name to allow Alt+Letter navigation. It works as it should in the development environment, but when you build the application the menus end up in a pile and the _ prefix has become a line above the first letter instead. Look at the attached illustration. Is this something anyone else have seen or can reproduce?

I can create event and case structures using scripting and put them into a loop etc., however I need to also make and link a number of frames, has anyone successfully done that using scripting? Adding a frame is easy enough, but to link it to an event or selector value seems to be more difficult. For a case structure there is a selector strings property, but that is read only...It seems a bit strange that you can make all the code, except give the frames their names / event link...so I hope it is doable. Alternatively: The end goal is to make a central GUI handler based on an event structure that can react to clicks on a large number of script-created buttons (hundreds, perhaps thousands, spread across different VIs). The event structure should fire when any of the buttons are clicked and identify them and perform the appropriate action based on the label of the button...Creating one frame linked to a mouse down for all the buttons would be one way, separate frames for each event a second way, but the linking must be automated as well...