Yair

If you wish I can set you up with TWO used napkins. I'll even put them in my pocket for a bit, so they can get properly crumpled.

First! It looks like there are still some tickets left, though. I expect they will be sold during NIWeek as people hear about the BBQ. If crelf would bother coming to the Challenge the Champions event right before the BBQ instead of chickening out using a lame excuse ( ) he could probably sell some there.

Post the code. It's a lot easier than following all that text.

I said it before, but I'll say it again, since AQ likes bringing up the localization issue - an icon with more than two (or three) glyphs is completely meaningless to me. Text is easier to create and (for me) easier to read, at least if it's large enough. Better yet, if you embed a Piet compiler into LabVIEW, you can now have your icons have extra code as well as the name. Excellent! P.S. I don't know if Mondrian's work is art or not, but I like it.

Even without bifocals (hell, I don't even have ONE level of focus), I agree with Ben. To paraphrase Altenbach, "if your problem can be solved by making the font smaller, the problem exists elsewhere". In this case, the environment needs to solve the problem of how to easily create recognizable VIs.

Before I turn in my card, here's exhibit A - some of the other sessions in my calender - Waterloo labs The compiler under the hood HALs LVOOP UI stuff

I've been having trouble setting up the alliance day sessions in my calender, but once I figure it out, I'm there, unless there's something super crazy awesome at the same time.

I'm not sure where you got that idea. Most closing primitives work even if there is an error coming in, as is explicitly stated in their help (see the error in section). I believe that there are a couple of exceptions to this rule, but I don't remember what they are offhand.

Anyone who wants this, PLEASE go vote for this idea: Adding a "(don't) wait until done" option to the Call By Reference node Did you try "LVx LabVIEW"? It brings up this.

Have you guys seen Google's App Inventor? Looks like this could add a relatively major push to the world of graphical programming. The programming itself is not in same style or depth of LV's programming model, but rather more like the stuff you get in languages such as Alice or Scratch (and in fact its puzzle block appearance is very similar to the one Scratch has and that page mentions they're related).

The hWndInsertAfter argument in SetWindowPos is what controls the window's Z order. -1 makes it always on top. I believe -2 cancels this, so you can probably just call it again with that value. In fact, you may not even need the original call at all. You'll note that my code did not have it, because I was only bringing the window to the top, not making it topmost. I don't remember if my code gives the window focus or not, but I believe it should.

You can try this. It has worked for me in the past. The key is attaching the thread's input.

You can use the Datasocket Read primitive to download the info from any URL as a string if you append "[text]" to the end of the URL (as in http://myurl[text]). I don't if there is such a URL, but you should presumably be able to use it to download the XML file Philip pointed to.

I don't remember the exact name the Excel object hierarchy uses, but it's probably the same thing. If it works on Excel files and has all the API properties and methods, you're fine.

ZIP and Excel files are two completely different things. For the Excel file, I assume the Save method provided by Excel has an optional password field. If not, you should search the Excel API to see how it's done. The ZIP file presumably depends on the library you use to save the ZIP file. If it exposes a method of password protecting the file, you can use that. If it does not, you'll need to find a library which does. OpenG has a ZIP library which might allow this. If it doesn't, you might be able to extend it yourself by calling the relevant functions from the DLL.

Sure does. Let's hope your nudges help. If they do, it'll make it much easier for me to attend Rob's session.

Not exactly. What I remember from previous years is that the morning keynotes and demos are all available, but none of the other sessions are. There have been specific cases where people (such as JKI) filmed and released their own sessions independently.

You're up against Rob Dye. Come on! Who creates these schedules?

I'm planning on coming. Anyone wants to share a room?

So now you can create 4 copies of the EXE and build 4 executables in parallel?

Next time have your speakers on. Your computer was probably saying "I'm sorry Dave. I'm afraid I can't do that".

See here - http://decibel.ni.com/content/groups/ui/blog/2010/04/29/creating-quality-uis-with-ni-labview--developer-days-2010-presentation The touch panel example is the relevant one. My understanding has always been that the module converts the code to C (like the embedded module) and then uses eVC to compile it. I expect that this is the source of most of the bugs, since it's a process which is considerably different than the desktop app-builder. Anyway, you should be happy you have tabs. If memory serves, the first version of the PDA module didn't have them.

One thing to note is that because the manifest VI can't belong to the class (if it would, opening it would load the entire class) you have to be careful not to load two of them at the same time, or you'll get a conflict. One generic way of working around this would be to embed the info in the VI's name (e.g. call it "Report_Manifest___XXXXXX", where the Xs are the details you want). That way you don't even have to open the VI. Tags are writable at run time, both in the IDE and in the RTE. However, if you want to persist the data in a tag, you have to save the VI, which can only be done in the RTE.

The first thought would be to look at the error number and description, see if it makes sense and do a search to see if others ran into such problems. I can say that maintaining a single connection is relatively simple (and has some advantage in that it can simplify the code if you design its wrapper as a singleton).

My experience with the mobile module (the PDA module, actually) is both limited and old, but I can say that in the past it was quite buggy. You should plan some extra time for debugging. As for the UI design, you can either go with multiple windows scheme (where only one window appears at every one time) or try to combine everything into a single window. I'm assuming you can't use subpanels, and tabs really don't work. What I did in the past was use a tab control, hide the tabs and used a ring to control which page of the tab was visible. You may wish to have a look at NI's UI community. Simon H. (if I remember correctly) posted a cool UI demo where the screen (a tab) slides in and out based on your selection. I assume the design is based on an app from one of the smart phones so popular these days (and I assume you can have a look at some of those to get some design ideas).