Jacemdom

I would have to see for myself to believe that it cannot be avoided or designed differently. Would it be possible for me to analyse this project?

It never came to your mind that all you "Power users" where not respecting the very nature of the tool you are using? DATAFLOW As for NI i believe that there are more and more people there who preach OO like they all been taught in school and that it takes a big effort for someone to clear all the OO stuff learned from the first day your PARENTS tell you that you INHERITED everything from them and that you are their CHILD and you are lucky to be in a middle CLASS family living in a first CLASS country, to finally grasp the power and simplicity of dataflow modeling. I also believe that you will have to completely destroy LV if you want a completely by ref LV. I also believe that there are still a lot of DATAFLOW fighters inside NI and to them :worship: One question to all you "Power users", Why don't you all stop complaining about what LV should or could offer and do a by ref Graphical Language of your own? You will have to realize someday that you are not asking things in line with the nature of LV and therefore not working for its advancement, but asking for the replacement of its founding concept. And if it ever succeeds, LV will be dead. You should/could/would then call it RefVIEW!

From : Implementing synhronized access to shared objects Basically i see them as shared/parallel ressources that need sharing mecanisms may they be direct or pointed(refnums) means. And i try to avoid them when possible, surely wont start creating more...I don't see the file or other refnums as the file itself, but just one more data that is needed by a function to accomplish it's task... Now that i answered your question, could you respond to mine : Using analogy, would the by ref implementation in LabVIEW be like designing a sewer system that enables the water and the treatment plant to go trough the pipes all together? If not, how would the sewer example need to be modified to fit?

Using analogy, would the by ref implementation in LabVIEW be like designing a sewer system that enables the water and the treatment plant to go trough the pipes all together?

I'm just doing my first exploration of the LVOOP implementation...First steps into LVOOP i may or may not go that way...one sure thing is that i'm not even thinking about going the by ref/GOOP or any totally disconnected objects way...i already have a simple documented method of designing an easily maintainable/upgradable/understandable large software with recuperable code. So i might just continue developping this method if LVOOP does not fulfill my needs of simplicity/clarity and especially debuggability/easytestability. I know that everything cannot be connected with wires and that sometimes a "shared dataspace" is needed between parallel process, but i create that shared space when i need it and only put the data that needs to be shared there. As for complex softwares, i think that a high percentage of highly complex softwares are created to solve highly complex real world problems that could be greatly simplified prior to creating the software and thus simplifying the upcoming software to automated the process. Sometimes it's worth questionning "the normal accepted way" instead of accepting it as is and continue building on top of it. Some other time you can only do gymnastics to go put another piece on an already unstable structure. Sometimes this...and sometimes that...and sometimes off...and sometimes under the sun, like for me in 15 minutes...

Salut. Considering the constant flow of new users to the LAVA forum and the relative "quietness" of info-labview, i'm wondering if everyone just made the move from info-labview? Or are the info-labview users on vacation or just to busy... If the info-labview list is to die of its natural end of usefulness, i have to say that i would never have been able to grow that far from where i started without it. I will have succeeded when i'm no longer needed!

2) I would definately prefer a jumpy probe than no probe. I'm used to the possibility to just poke around everywhere on the wires to debug, but also to understand code. maybe you could create another kind of probe, Default, Custom and Jumpy! :laugh: 4) And in this case, the parent class "shape" is an empty cluster so this is why i get an empty probe... Is it possible to make a probe that uses a dynamic dispatch? I am trying but i get

That is my question...How can you make that possible? How can you make a "follow the datawire debugging" scheme in a by ref design? I don't see how one can follow the data in a by ref design...

I also share that idea, i only differ on the ways to achieve this. I believe that one should stick to the nature of the tool he is using and LV is a dataflow language that focus on by value design. I also believe that forcing it to be by ref, creates unneeded complexity in the architecture. Dataflow designing/programming brings a new simpler way of solving problems and i don't believe that the methods used to streamline "archaic" textual sequential languages like standard OO should be transfered "textually" to a "graphical" dataflow language. Just like stated in the LabVIEW Object-Oriented Programming: The Decisions Behind the Design document. One must not forget why OO and all designing methods were created. REUSABILITY...Reusability of code in other code, Reusability of code by other programmers. This to allow multiple programmers to work on the same design, simpify maintenance, and the ultimate central point of all this...lower the costs! LabVIEW already had lots of tools to attain those goals, without the need for the added complexity of by ref "unconnected" code", that creates a gigantic number of files enabling the CS programmer to brag about 1000 files just like the old days when they bragged about 1 000 000 lines of code and also have job security by being the only ones who can understand it, especially not the domain expert that he always works for. The way i see things, the simpler the better. I recently changed jobs and got responsability for some LabVIEW apps that had hundreds of files and when i finished with them i had shrunk them by half just by removing the "utility" VIs and files needed to support one of many flavors of "by ref" designs. It even went to the point that one of the center's clients, who was already doing business with the center i work for, who wanted to start using LabVIEW for its simplicity, was delivered a "by ref" kind of design based on dynamic events, and was seriously considering dropping the project, and also LabVIEW, due to the complexity of the thing. I had to work hard for them to believe me and let me redesigne the app so i could show them that it can really be simple. What i get from this forum is more in the lines of "We want it to be what it is not". I don't remember who said this or when he said it during NI-Week but i remember the essence of the word : "It may even be possible with LabVIEW, to give the tools needed by the domain expert to translate is knowledge directly to the computer without the aid of the CS guys" I think it was in the graphical system design summit and i remember seing Jeff Kodosky ther also. I will have succeeded when i'm no longer needed!

Salut. Making my first steps into LVOOP and here are some questions about the project discussed in the presentation (Introduction to OO Dev by Robbie Gehbauer) available at http://secure.niweek.com/published/I80_Geh...resentation.zip Exploring ShapesTest.vi in Shapes.lvproj 1- When probing Line.lvclass i get a picture control...where does it come from? 2- is it possible to probe the actual data on the input of Draw.vi in the for loop? If not is this planned in future versions? I only get a probe that tells me the actual datatype... 3- In reference to number 2, how can i look at the data that flows through if the probe does not work?

1) Look into the function palette-->Signal processing-->Waveform conditionning 2) One of the simple ways would be to acquire the data once before looping and substracting the values in your loop.

No it does not...but if you continue you surely won't... I don't beleive that 20 or 30 (even 100) "power" users qualifies for the majority of users...and when i read a huge demand i expect a huge number of users and if there is a huge number of users i expect it to be the majority... The majority of LV users try to solve measurement/instrumentation/control problems with a tool named LV...a lot of people (including me) on this forum use that tool in areas it was not initially designed for and expect the tool to fit their needs. If the demand is so huge, don't even have to push for it, NI will deliver it as it will become priority number uno... LAVA (LabVIEW Advanced Virtual Architects)...i believe that the majority of LV users don't even know what a software architect is really doing on a day by day basis, let alone what a LabVIEW Advanced Virtual Architect does...not even sure i know what a LabVIEW Advanced Virtual Architect is doing...

i don't see objects when i model (software or any other modeling)...i see data and functions that act upon it...i don't unite them as one to create objects...i see them seperated... I created a similar relation about 5 years ago, to be able to differenciate the LV concepts from the OO ones, that went :In LabVIEW there are containers (contain data, wires, globals, queues etc...) that are similar to the properties of objects and there are functions (transforms the data, VIs, VITs, LV Blocks) that are similar to the methods of the objects. A definition of a container is a domain (Type def cluster) that is similar to an OO class. So i created a way of modeling the architecture of an app entirely using a naming convention representing this. For more details see http://forums.lavag.org/index.php?s=&s...ost&p=17238 As for I don't know how to qualify the corners, but one thing i know is that i'm not in the same corner than the ones who believe that LV lacks native by ref modeling tools. If NI wants to add them in the future, so be it, as long as they never forget the original simplicity of the dataflow implemented by the fathers of LV. Emotionnaly i can say that all the discussions and complaints i have read on this forum, since LV8.2 came out with new tools to push forward the designs of those who have used LV for what it was, a DATAflow language, have made me ...and i also believe that i'm the only responsible for getting as i was the one who read all the info, knowing in advance i would get ... I have now let it out , and can continue in my corner :ninja: preaching about DATAFLOW (i don't believe in that the wires can solve evrything, sometimes data needs to be shared and LV as a lot of different tools to do so, no need to have a by ref OO). Can "by ref" OO offer, you have bug, follow the wire?

I looked into the doc and the only solution i saw ther was to setup a proxy server, wich i don't want to do. Could you put me in contact with someone at Shangai to see if this is the solution they implemented? For the time being i deactivated the SCC and returned to the tools i used before LV8. Basically a function that puts all the modified code in edit when i start it.

How can it stops itching if you don't stop scratching? Could you point me to the data that made you reach that conclusion?

First for the locking mecanism : I believe that Aristos cleared that issue http://forums.lavag.org/index.php?showtopi...amp;#entry17439 And know some OO (ObjectionsOverload) It never occured to you that you where using the wrong tool to do OO, and in the process making thinghs more complicated than it would be with a OO tool? Could data be just seen as data? Is a motor really and object or a function to transform air and gaz inputs into mecanical force output? And then im back to the old text languages methods where i would have to code a UI to test my function...also take note that when built into exe the front panels that are not needed are removed... I strongly believe that OO is not a representation of the "real" world, but more a representation of the "ideal world" that some people think or would like to live in. Example : In the OO world you create an object called "plastic bag", you use it then destroy it. Its gone, evaporated, no traces, by by... In the world i live in, you create an object called "plastic bag", you use it then destroy it. It pollutes... Some people see objects and believe that they exists and generate data, some others believe that the data exists and the objects are a particular state of the data...if we live in an object world, who decides where are the boundaries? This discussion reminds me of all the conflicts that arose when an old theory was challenged by a new one that enables a more simplistic way and a larger domain of applicability to the transformation of our surroundings. Particularly of the conflict of the flat world vs the sphere world that went on a couple of centuries ago. And i found this website that could give some encouragment to the OO advocates on continuing their mission of propagating the "everything is an object" concept. Here is an excerpt from there mission statement :

I tried the autotoll when it came out and deactivated it as fast as i could... Tried it again in 7.1 and lasted about 5 minutes... I recently made the move to LV8.0.1 and in the process decided that if so many "referenciable" people where praising its virtues, that there must be something there... It took me abour 2 weeks to adapt to the new way of coding until i got back up to the speed i was before...i believe it is basically due to the fact that with "tabbing" you don't think about where to position the mouse, you tab. And with the autotool, mouse placement is crucial... It also took me sometime to stop tabbing by habit... But i am now convinced to stay with the autotool... Why don't you use an enum for the selection so that your code is auto-documented, as the enum string will end up in the selector case? You can also use the units letters. Ex : 1.2345m(mili) will give out 0.001234 1.2345M(Mega) will give out 1234000 This only changes the properties of this particular instance. From LV Help : SubVI Node Setup Dialog Box Right-click a subVI icon on the block diagram and select SubVI Node Setup from the shortcut menu to display this dialog box from the shortcut menu. This dialog box contains a subset of the items included in the VI Properties dialog box. Use this dialog box to set options for only the current instance of the subVI. Use the subVI execution items in the VI Properties dialog box to set options for every instance of the subVI.

I would suggest to look into the .NET framework, i be;ieve you will find something there. Or you could use the attached VI to change the timeout of the screen saver to a maximum of 9999 minutes. Download File:post-731-1160055219.vi

One minus...i have to cross the internet to get in my Perforce depot, this causes LV to hang(1-3 seconds) frequently due to all the queries made to verify if the file is in the depot, checked out, etc... So after a while i disabled it...

[quote name='Lars-G

1- I can't make it to work, could you send me a VI? 2- Where did you get the 17 = SPI_SETSCREENSAVEACTIVE?

maybe you could use a cascading contextual menu instead. See attached example Download File:post-731-1159806566.zip

Here is a resume of the methodology i use. I use a 3 part naming for functions and 2 parts for containers (globals, type defs, etc...) seperated by underscores. The firts part is the nature of the file. The nature identifies the type of file. It answers to the question : What am I? Functions FVI=Flow VI PVI=Polymorphic VI CVI=Constant VI UVI=User Interface VI WVI=Wrapper VI(FVI ou SVI caller) Containers GLB=Global variable TD=Type definition STD=Strict type definition RTM=Run-Time menu The nature is or was there to permit further automation of code and build creation. Example : i could find all the dynamically called VIs just by looking on the front panels of the WVI files. All the communication with dynamically called VIs is done via this "wrapper" VI. All standard default files are FVI, only the exeptions get another name. The second part is the domain. It identifies the data domain of the container or upon wich domain the functions act's on. It answers to the questions : What do i contain? (for containers) and On what do i act? (for functions) Domains can include a hierarchy seperated by underscores ex: Motor_Axe_Speed. The first domain of a file in an app (not in shared libraries) is the app name. That way i never had name duplication issues. I also use an abreviation table in order to keep the file names not to long. Ex :Microsoft becomes MS, LabVIEW becomes LV. The third part is for the functions and is the actual action of the function. It answers to the question : What do i do? Examples : MyApp folder could contain : FVI_MyApp_Motor_Disable.vi FVI_MyApp_Motor_Enable.vi FVI_MyApp_Motors_Count.vi FVI_MyApp_Motor_Speed_Set.vi FVI_MyApp_Motor_Speed_Get.vi FVI_MyApp_Motors_Speed_Set.vi FVI_MyApp_Motors_Speed_Get.vi TD_MyAPP (Contains TD_MyApp_Motor) TD_MyApp_Motor An example of my librarie : FVI_MS_XL_Close.vi FVI_MS_XL_Workbook_Close.vi FVI_MS_XL_Workbook_Create.vi FVI_MS_XL_Workbook_Worksheet_Create.vi FVI_MS_XL_Workbook_Worksheet_Name_Set.vi I'm currently fermenting how to merge it with the new LV8 implemented concepts. What i liked the most about that methodology is that the project folders where simple to follow. A lot fermentation went into why to order nature_domain_action while almost everything that i saw was action_domain ex: get motor speed.vi and if you look at what it does in the folders is that it groups all the gets and sets and all other action together and if you put the domain in front of the action, all your files group automatically by domains and i like that better than the other way around. It also "Modularizes" the app without the need to add subfolders for smaller projects. If someone would like to see the complete document(french) just ask. For me : filename__toolkit__project.vi would become project_toolkit_filename.vi