jgcode

I am ashamed to say it won't be my first time... (The digital age is a b#?ch) I like Vugies ideas in general (and artwork). I don't have a 2009 shirt so I don't mind I just ordered L, 5-12 days shipping - can't wait.

Yes, I agree, marrying your sister is a little weird and should be censored

Option to Add LabVIEW Project Library To Parent Library and Set Scope in Source Distribution Build Spec

Unless it tastes nice?

That is correct

That's ok as VIPM 2010 will have a cool new feature that will have you covered

Good question. A few reasons: Traditionally dependencies go in the .vipc file only I can't script a .vipc file, so dependencies are a "pre-made" file and during the build process the file is added to the zip just like any other support file, whilst the package gets created from a source distribution each time. Majority of times people have the dependencies and just want the new package anyway If I want the package in the zip, then having it in the .vipc file will add extra size. But you are correct it is a valid way to distribute code, but I can't script it at this stage. I am guessing you would prefer it in one file?

No probs. I would also suggest, if you have not done so already, spending a little bit at data socket, shared variables and FP binding. I didn't think this was in the CLAD or hadn't seen it in the sample exams and got whacked with 3-4 questions on it back when I took it. Just don't skip over it like I did.

Hi Mars The best resources will be on NI.com including the webcast. Also if you have Basics/Core I/II manuals you can get your hands on, they would be worth a read. If not, I agree and suggest you keep sitting Sample Exams until you happy. Good luck

Yes, in essence this is how Hector should be used, all state information is contained in the objects, so (if you want tight code) any message/command/state should be able to be called in any order - it should be up the object if it is logical to perform action. Of course you have have the flexibility to do what you want for any simple/complex GUI using Hector. I do have it, that is what I meant when I referred to HFDP. I haven't dived deep into it yet as there is so much other stuff to do. But it is on my do-list (keeping in mind this seems to grow exponentially). Ok, my aim was to give you a simple example (maybe too simple by calling it dialog?), then enquire how you would expand the design without a rewrite of the pattern used. Now what happened now if the requirements changes to include: If user types in invalid entry for "This String" then display help text and disable Ok button (and this list grows to 10 others like this etc...)My thoughts are still that Hector would be great here. Yer, I read that post and also Omar posted here somewhere about some Ideas and stuff they do wrt to UI Testing and automating it. Interesting stuff. Yer, that what I try to do. Its more testing the GUI acting on the functional part that I am interested on improving. The only way I know how to do it is manual testing. Cheers, I'll take a squizz.

Thanks, but due to the orangutan ancestor blood in me, its all been automated through a script

LAVA keeps getter cooler, and with the recent upgrade, you can now upload multiple files to the LAVA CR. Before the rules were to upload a .zip contain XYZ. The upgrade allows you to post a package (.opg/.vip) version too! The first time I have done this is with this project the other day so the readme is actually referring to the .zip (and I may need to brush up on my grammer if it now contains artifacts that are now confusing). Are you sure about that? Yes, very I think I am assuming you (and others) are familiar with VIPM nomenclature (and my interpretation of it)? So I will parse this string: Dependencies are what you need to install with the package to make sure its not broken (simple really) The .vipc file contains a list of dependencies By this I mean the dependent packages are listed by name but are not physically inside the .vipc file. However, in this case, the exception is the Icon Editor API package My logic is that some files are easy to get to (through the VI Package Network) and some are harder to get access to (e.g. Icon Editor API you would have to go to the post) So I include the harder ones in the .vipc file as a physical package - as I think this is generally easier for the user. Now not to confuse issues, in this project I have now included all other reuse VIs internally in the code (by namespacing them etc...) so the .vipc file will only include the single Icon Editor API dependency: Actually I would rather have no dependencies at all, the reason for this, in this case, is that NI's Icon Editor API calls VIs outside of symbolic paths (e.g. vi.lib). This means that if you move code (i.e namespace and include with your own release/project code) all linkages will break! The workaround is to get the user to install the package separately. *** Also here is an example what I am talking about, and what the .vipc file would look like: When the file is opened in VIPM you can see that there is an package-glyph associated with one item and no-glyph associated with the other item. So the package-glyph means that physically that package is in the .vipc file, the no-glyph meast you need to BYO All you need to do is Tools>>Apply Package Configuration to install the files. Hope that makes sense?

Ok as so most people don't care, I will drop it. Thanks all for posting.

Yes .How's that? So its in the .zip version not the package version downloadable. But you can get it here from my post too Cheers! -JG. If you have any feedback to make this better please let me know too. I would be very interested in what you think.

Yes, but I am not talking about the .zip file I am talking about the .ogp file - which is .zip but not extracted in the traditional sense.

I guess you could be right, but it could be more the point of checking that your download is ok (from a transfer point of view rather than security)? Anyways, there might be other reasons for allowing text files besides my example, so I was curious to see what others think.

I thought I would post this here rather than LAVA CR as it a technical request as opposed to a discussion on code. Now that we have the ability to upload multiple deliverables, would it be possible to allow text files to be uploaded too? The reason being I would like to include a text file with a checksum in it, for the package. I have included this in the zip file but I thought it may be handy if someone just wants the package version and the checksum, rather than download the zip? (I guess I can always just post it up) Thoughts? Cheers -JG

Changelist: 2.6-1 2010 06 28 - Fixed (): Classes as Sub-Libraries caused error as Namespace was incorrect Damn! forgot about Neil's post, have done that now - for next release

Yes, that is what confuses me, I see a lot of NI folk in pants in the pictures. Should we pack a jumper? (Ok I missed Darren saying to bring mittens, so I am guessing yes )

Wow! Tell me it nice and cool inside the convention center?

ROFL! Great find Francois - I just had to post the vid <object width="640" height="385"><param name="movie" value="http://www.youtube.com/watch?v=bqJE5TH5jhc&hl=en_US&fs=1&"><param'>http://www.youtube.com/watch?v=bqJE5TH5jhc&hl=en_US&fs=1&"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src="http://www.youtube.com/watch?v=bqJE5TH5jhc&hl=en_US&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></object> Get some nuts... fool

Sending Packages (.ogp, .vip, .vipc files) to NI Support is an acceptable way to submit code

Who is Scooby? And yes I used parenthesis as I thought you would have issue's with NI's (theirs) basic SM implementation too I think you are onto something here, it has a nice ring to it. Does that help Yes this is the trade off I am willing to except based on the module's size. But that module is normally a GUI VI. It is also the reason for my question about how do you handle small dialogs etc... (which I am still interested to know) But the way I like to program this is not so much exposed functions like in your code example. Functions exposed like this on the block diagram of the main VI is bad and way too hard to test. It more a Command Case to run an Integration (another NI term) i.e. the Top Level code (GUI) is calling the bottom level code (which are methods that encapsulated functions) in the correct order and passing in input data. If I have a basic Get/Set (Ok/Cancel) data entry screen, I really don't see the point of implementing something elaborate if I get the same result using Hector. Also for small projects, and charge by the hour/day stuff, sometimes I honestly can't justify the time. I want to ensure that using Hector is scalable for the future however, if it was a reusable framework (that was my other question about what you have posted) I would use it. Also when it comes to GUIs how to you test your code? Are you able to automate testing of it some how? The above issues you mentioned (datatype checking etc...) are great points, but in terms of GUI I don't have any way to automate/check/test these other than Usability Tests, but am very interested to learn more or how I can do this better. Would your implementation help towards this issue?

Damn, how hot is "hot" if you can't walk a few blocks to get there? Do people melt that time of year if they stay outside too long or what?