i2dx

seems you need a new machine, eh? but to be serious: I prefer to have all the VIs in memory, instead of loading them from disk, each time I open them. I have 2 GB Ram on my development machines, and that works fine, even with my largest projects. RAM is cheap, so why stress the disk - which is furthermore the slowest part of your PC ... cheers, CB

yea, awfull, but luckily I have my "project duplicator tool", which excacly does, what the source code distribution function is intended to do. I hope to have time to add a "create Project" function in the LV 8.x version, soon. YOu can find that tool in the Code reposititory I do not agree completely. I expect things to become better with a new release. In my eyes LV 8 was a marketing driven release - the NI Sales department became nervous, because NI missed the goal to release a x.0 version every second year -> therefore the engineers had to produce a release, which they could sell - ready or not. But maybe my expectations are to high: If I get a "project exporer" I expect it to work as perfect as e.g. the project exporer in Visual Studio does. And the argument "you don't have to use it, if you don't like it" does not count. Sooner or later you have to use it, at least to build an executable ... cheers, CB

I think it will work my major mistake when switching from 7.1.1 to 8.0 in a running project was my enthusiasm was to expect a seamless upgrading like from LV 6.1 to 7.0 or 7.0 to 7.1. Now I know there will be some struggle and I have to change my "good old habits" when working with the project exporer and so on - next time I'll be well prepared and I have "no" pressure from the customer. One reason for my rant was e.g. that I expected that some bugs in the TCP/IP communication VIs of the PDA Toolkit will be fixed, but they were not, furthermore I encountered new ones, which made it even harder to solve that problem. => the whole work for upgrading the project was more or less "reactive power", because there were no improvements to the code, but I had extra struggle with the new LV Version. Imagine that and combine it with a project out of time, over budget and a overstressed customer ... that's a bad mixture cheers CB

no problem, that's ok ... I never used LV 8 in production, I tried it and this thread is one of the results . I'll give LV 8.2 a chance with a new project next week, we will see, what happens . Maybe I will come out with an "old style VI Close tool" cheers, CB

hmm ... somtimes the best ideas grow from such "evil" ideas changing integer and double wire colour will not hurt so much. Most LV developers I know do not care about coercion dots [maybe you should make them 10x bigger with maximum contrast ? ] But changing the meaning of the stop condition in a while loop - THAT will cause much impact , and to top that: change it each time you restart LV :ninja:

hmm, why do I get the *evil* idea now to write a "LAVA post obfuscator" ? cheers, cb

Hi folks, has anyone allready got the LV PDA Module V 8.20 ? In my August issue of the DevSuite there was only a CD with the LV PDA Module 8.0 for PocketPC. Or: has anyone information, when this version will start shipping? Thx, CB

no, that's quite easy: just use 2 Send / Read VIs. with the first one you send the length of the data, with the second one you read the data, with the excact length:

Ok, that makes me sleep better now, thank you ...

Hi Folks, I am not really sure, what happens with System VIs, if you use them in a reentrant VI. E.g. in my application I have a reentrant VI which handles the TCP/IP sending and receiving with the client. The VI is reentrant because it works in a multi connection server, which serves several clients. The question is: Does the reentrant VI create it's own instance of the System VI, or can it happen - e.g. if the transmission is laggy - that one TCP Read VI blocks the other instances while waiting for the data? I have made several tests to figure that out and it seems that the answer is NO, but I would really like to be SURE with this ... thx! CB

me, too. When LV 8.0 came out I tried to migrate one Project. This "experience"* led me to the oppinion: "never change a running system" . I will use LV 8.x for new projects, but as long as I am still working on the old ones, I do not think about upgrading, if there is no urgent need ... *I went back to 7.1.1. with that project ... cheers, CB

hmm ... if you want to monitor the electical signals? -> then I would use a M-Series DAQ Board and some custom made connectivity (which brings the signals to a TTL Level) and log the data with the DIOs of the Board. Why M-Series? -> the DIOs a really fast! and depending on the bus-speed you have to logg really fast. I tried this once with RS232 and it worked. It was - in a way - cute to see the Data on the bus ... If you want to monitor the data, then I'd buy an USB GPIB-HS (I have one, and like it ...) and use NI Spy, as David said. CB

that makes me consider, if the price for the next coding challenge should be a one year premium membership for free? nice. I like SOAD. [i like heavy music at all - I started with Deep Purple in the seventies ] AND: heavy music is a good background, when driving fast CB

ok, maybe I have a cure: <embed style="width:400px; height:326px;" id="VideoPlayback" type="application/x-shockwave-flash" src="http://video.google.com/googleplayer.swf?docId=4050992276292239673&hl=en"> </embed> just listen 2 hours to this amazing slipknot video and you forget this barbie stuff :ninja:

I knew you have an inspiration 4 me thx cb

that looks close what I want to do: a little explanation: I want a "UPDATE Simple" and an "INSERT Stimple" VI for my ADO-Toolkit. As log as the data come in an Array, it's easy to create an INSERT/UPDATE SQL Statement. But if the data are a cluster or an array of clusters, things become more difficult. I know the NI Database Connectivity Toolset uses a polymorphic VI for the common types (String Arrays, Number Arrays, etc) and a Variant input for the other types. But I wanted to be better. My first idea was to use an "anything" input - like the "to variant" VI does, but it seems - that will be hard to archieve - if there is a way (maybe Xnodes would work ...) If I had a "anything" input, I could flatten anything to XML, parse that XML and get an array of Type + Data which could be easily converted into the desired SQL UPDATE or INSERT Statement. Variants - or better - flattended variants - are a crutch which could work, but it's alot of word and - as the type descriptors change with each LV version, I'd like to avoid that. I'll think about that and thank you all for the input! cb

jopp, I did this - 2 or 3 years ago, and I called that "dynamic cluster" - a cluster which existed only by reference. You have to figure out how the type descriptor array works, then you can create clusters in a way you want. the only drawback is - if you want to access them, you can do this only if you convert them into a variant. You cant create any bundle or unbundle nodes on the BD with this cluster. ok, Xnodes could be a solution - but - there is the license / documentation issue. Because I'd like to have this feature for my ADO-Toolkit I better not use Xnodes, I don't want to get in trouble with NI ... thx anyway, CB

yes, I want the output different on the input type. an other possiblity would be, if I could figure out, how to access the elements of a cluster tranformed into a variant. e.g. if I connect an error cluster to a "to variant" vi on the left side and create control as a output, I can see the cluster elements in the Variant Indicator. If I could e.g. convert them into a string array {{'name', 'value'}} or something like that, that would help a lot ...

Hi Folks, is there a way to get an "anything" Input or Output to a Sub-VI, which adapts itself to the type of the input? Or is this restricted to System VIs? I don't think this can be archieved with polymorpic VIs, because you have to create an instance for e.g. every possible cluster type ... thx, CB

LOL ...

oops, that seems to be true. I just looked through my brand new August 2006 developer suite CD kit, which arived last week and - you guess right - there is no cd for PDA Module for PalmOS any more. 8.0.1 seems to be the last supported version ... has there been any anouncement that NI will discontinue the PalmOS support before the release of 8.2?

nur in norddeutschland

don't worry, these new features are in use and are apreciated by the developers. the scrollbar in arrays was worth "sitting" ovations during the LV Day in Duesseldorf / Germany. This is a feature, users demanded for a long time, and everyone was able to understand quickly how it works, and what the benefits are: "Hey cool, scrollbars!" The response to XControls or Shared Variables was not that enthusiastic. But not because the users do not like them, or don't recognize the demand for that feature. They have to play arount with that, to understand wether they like/need it or not, what this is good for and what they can archieve with this new technique. One Problem about public feedback or public discussions in in general, especially in forums is, that people to come here to discuss problems, bugs, missing features, etc. and not to praise the benefits of new features in long discussions. If you want to find this, you have to search for posts like this: "I'd rather use shared variables, that makes it much easier for you to transfer [...]". No feedback is good feedback But just to please you and just to work a little bit against my evil "da big bad NI basher" reputation: I like the array scrollbars and I like shared variables. I was a little bit angry about the shared variables - because they came 4 weeks to late for me;) Hmm ... I never had problems with the old saving dialog. If you give me a "close immediately" button in the new one, I'll immediately shut up proschd! CB

WHOW! allmost incredible!

In my first approach to the LV OOP in LV 8.2 I tried to implement a really simple task: myClass (or TestClass in the LV Example) is a very simple example of a class, which consists of one member (I32) "myMember" and three methods, constructor ->"init", "increment" and "get". On the right side you can see the implementation of this task in C# - I hope most of you are able to read this. I implemented that in C# and LV 8.2 to compare and I experienced that LV Objects have no mechanism like e.g. C# Objects to store the value of the member-variables automatically. In my understanding a method called on an instance of an object modifies the value of the member and stores it in the member value (not always, but in most cases - of course). The upper example should work properly, if there were such mechanisms, but it does not. You have to use a shift register (lower example) instead, which leads me to the conclusion, that the LV Objects are in the current release of LV not much more then a protected cluster with *some* features that point in the direction of OOP And from practical point of view, I miss a possibility to access an instance somewhere else in my code, without the need to drag the wire through the whole and all BDs. Of course I could store the "Object reference" in a Old Style Global, or in a global variable, but excuse me - that thought is really ridicules ... I hope, that this input has some impact on the further development of LVOOP - I am looking forward to your replies: you're welcome to comment that! Cheers, CB the code:Download File:post-885-1156497555.zip