Yair

And just note that the simple loop example will overrun the I32 limit after only a small number of iterations. With I64 (or U64) you should be better.

I wouldn't miss it either. It always annoys me when threads appear in outline mode (it happens sometimes).

QUOTE(rolfk @ Jun 12 2007, 09:20 AM) Yes, in the few occasions I needed a splash screen that's what I did as well. It's just been a while since the last time I did one.

QUOTE(alfa @ Jun 12 2007, 08:54 AM) Ahhhh, isn't it nice to see enemies stop fighting and work together towards a common goal? QUOTE A Romanian police officer has 6 times my salary. What salary? You mean you managed to get a job? Well, at least alfa can spell LabVIEW properly...

I haven't had problems like this, but you can try setting the process (from the Windows task manager) to run only on a single core to see if this is really the source of the problem, but you should note that this change needs to be made manually each time. One other option is changing the priority or the execution systems of the DAQ VIs (in File>VI Properties>Execution) to the DAQ thread.

Congrats.

Setting the FP.State property to Hidden should NOT minimize the window. It should make it disappear immediately. If you're still seeing a button in the taskbar, that's because LV creates a second window by default (if I remember correctly, it is precisely to keep the application open). As mentioned, when you remove the top level VI in an application from memory, the RTE closes the application. What you need to do is this: Add the line HideRootWindow=True to your app's INI file under the [application name] section (you might need to create the section). This will make the application have only a single window. In the splash screen VI, have the VI open a reference to itself before setting its state to Hidden. That should keep it in memory.

QUOTE(Tomi Maila @ Jun 11 2007, 09:06 PM) Thanks. Good work, indeed. P.S. you might wish to proof-read that wiki article. It has several grammatical errors which would be reasonable in a post, but are more in-your-face when you're talking about a long text. Maybe I will do it if no one else gets to it first.

QUOTE(Mike Ashe @ Jun 11 2007, 10:17 PM) Yes, but not recently, and that was my point. QUOTE I'm not going to filter back through all 16 pages of this thread, but ... have we ever seen any evidence of this? Some of alfa's original posts both here and in the NI forums refer to actual LV code, so it seems he did have some connection with it.

*sigh* Where's the funny stuff? Michael, what's the threshold for invoking Godwyn's\Kring's law and for locking a thread?

QUOTE(Aristos Queue @ Jun 11 2007, 06:58 AM) Not that I would want to argue with the all-mighty LV R&D, but that is not exactly what Rolf said. I don't know how the disassembler works, but what Rolf said was that it finds the pre-built assembly code which is responsible for loading the RTE, etc. and that it can not actually find the machine code included in the VIs. This would seem to be supported by Jeff's second experiment and would make some sense, because we know that LV generates the actual machine code when compiling the VIs and that putting the VIs into the exe is basically the same process with some optimizations (removing FPs, BDs, debug code, etc.). I do find it weird that the disassembler does not go through the entire binary executable, but as I said, I don't know how it works, so I will just assume that what Rolf meant was that it knows how to find the basic executable code, because that's in a standard location and it doesn't look for the rest of the machine code because as far as it's concerned the rest of the exe is not machine code.

Maybe it's just me, but I can't see the blog post. The last post in the blog is from May 22.

A simple search can work wonders.

I posted my example over here (replies 12 & 13). I like it more because it allows working with individual controls.

This change was done to be compatible with the Windows Vista executable format, so you can no longer treat the EXE file as a directory. One workaround would be to build an LLB of all the support VIs. Have a look here for more details.

Well, not as funny as the Linux guy in the Get a Mac ads, but still :laugh: .

QUOTE(tcplomp @ Jun 9 2007, 08:41 PM) :laugh:

QUOTE(Michael_Aivaliotis @ Jun 9 2007, 08:19 PM) Or, for a list of all the network adapters, follow my first example with this modification.

You might wish to read this.

QUOTE(tcplomp @ Jun 8 2007, 07:07 AM) Indeed. See Greg's (!) explanations in http://forums.ni.com/ni/board/message?board.id=170&message.id=191622#M191622' target="_blank">this thread.

Another way to get your IP addresses (although not the MAC addresses) is to do this: http://forums.lavag.org/index.php?act=attach&type=post&id=6050 As for the MAC addresses, you can use the command Michael supplied to call the System Exec VI and parse the output. There are also probably some Windows API functions to do this. I'm fairly sure Rolf Kalbermatter (rolfk) posted some either here or to the NI fourms, so you can search there for his posts.

As said, you should include a link to this thread over there. That way, if someone does want to answer the thread, they can click the link and see which responses you already got.

Cross posted to the NI forums. When cross posting, it is considered polite to add a link to the other thread (which is what you should now do in the other thread).

QUOTE(Jeff Plotzke @ Jun 6 2007, 08:33 PM) Suddenly, a shot rang out! A door slammed. The maid screamed.

QUOTE(Tomi Maila @ Jun 6 2007, 08:05 PM) Tease.