ShaunR

If you are running under windows, turn off windows ndexing.

From my experience it's not so much the size of the file. It's the size of the hierarchy. If you have 1 VI that is 44MB it will load a lot faster than 10,000 VIs @44MB. Although I would want to debug the former . A splash screen means that you only have a very small hierarchy to load before you can display something. It also gives you the opportunity to "incrementally" load you application For example, you may have a "hardware check". In running that, you have loaded quite a few VIs that you probably use in the main app (and done something useful) without having to wait for the whole app to load.

Well. It's the same as the image ....but

If it's your dialogue. Why not just bypass it completely or put a switch in to disable dialogues (maybe log it to a file instead). If it's not your dialogue (i.e in another application) then there are some suggestions here.

Like this?

Probably is if you are talking to architects and experienced clds. But "most" labview programmers aren't and the limit of IPC conversations tends to go as far as a producer consumer loop with queues and that's about it.. I've yet to see a student, electrical or electronics engineer (LabVIEW is still seen as a secondary skill in many companies eyes) talk about IPC and messaging systems. And I've worked, and interviewed many. And those are exactly the apps that can fall fowl of this "feature". I've commented many times about how I feel that events have been neglected. So you are preaching to he the converted here. Well. Actually, in the strictest sense, Events shouldn't have a timeout at all. An event is either signalled or is not not. No other language I know of has event time-outs and if a programmer wants to time-out if no event is received within a time-frame, then he has to create a timer that gets reset when an event fires. This is probably why the event case is as it is. The windows forms message callback (Wndproc) just has a timer that gets kicked on entry. As for not registering unless you need to react. that is only applicable at design time. What if you have configurable alarms? You will still need all the cases on the off-chance that a user will want to register it and receive feedback. thats one of the more useful (but rarely seen in LabVIEW) uses for events. Unfortunately, I don't think it is "cool". At best it's unexpected behaviour and explains (IMO) a lot about problems people have seen with xControls.

I would actually categorise it as "unexpected behaviour". If it is a bug or not then depends on whether it was specifically designed to not timeout under certain circumstances. My guess is it wasn't considered and "most" developers would want a time-out to, well, time-out I think it's probably because most people only use the event case for the UI (and generally wire -1 to it). And only a few are brave enough to base a whole inter-process messaging system purely on events.So if anyone is going to find it....it's you

I'm in on the Justin and JG bandwagon. (not very crowded yet ) Doesn't anyone else think that a "timeout" that can never time out is in the least bit strange in concept? Sure you can find a use case for it. But I bet there is far more instances of head-scratching and cries of WTF. On the shoot yourself in the foot scale of 1-10. It's a bit of an 11. It's also one of those "issues" that you come across from time to time where the whole app just doesn't work, but when you try to debug. Everything works fine in isolation (or if you slow it down).

IC. I thought I was missing a trick That's a lot of work - Kudos for even considering it. I took the decision a while ago to cater for cross platform in Labview rather than support my own wrappers or modifying pre-tested API source. I figured that platforms change rarely, but dlls change often. If I just interface directly to the DLL from LabVIEW I could also take advantage of tested, pre-compiled binaries from the developers and just download and overwrite. But I am not as comfortable in C as you are. I also don't have to contend with backward compatibility to LabVIEW versions from 10 aeons ago (when there were no things like "pointer-sized" int). But presumably that could be worked around with the package builder too. I think there are a lot of people lurking on this thread waiting to pounce once you announce a 64 bit version.

You don't expect me to read threads do you? Apologies. He's all yours

Also...... you need to put the boolean control terminals inside of the case for that control otherwise when you press them they will not pop back to thier FALSE state. e.g

As far as I'm aware, lv can only load a dll of the correct bitness so I envisaged at least 2 zwrapper dlls (one x32 & one x64 if you stayed with an intermediary) even if you managed to thunk down to a single 32 bit zlib (expecting 4 dlls in total though). There's obviously a trick I'm missing and can't wait to see the solution. PC on next day delivery?

Is it the wrapper dll or the zlib dll thats crashing?. I've have a zlib dll that I'm using successfully in LVx64 if that's what is causing you problems. I'm not using it for zip files as I'm currently using the LV shipped ones (although it is compiled with the minizip 64 bit functons - not sure if you use them or not ). It passes all the zlib and minizip tests and labview isn't complaining (or dying) when compressing buffers. Anyhoo. I'm attaching it in the hope it might save you a bit of time.

I don't think your program is doing what you think it is doing. Your top loop is updating the indicators every 1 second. And your bottom loop will show you the new value about 0.25s after that. The "lag" is because you are only updating the command2 indicators every 250 ms. Set the 250 ms wait to zero and they will change instantly. You would be hard-pushed to measure the read/write time of a local variable (which would be a few cycles of the computers clock).

I think that'd be great. There's very little in native labview for encryption (for free ). It must be nice to have so much free resource to work on your little nuggets

The only real (practical) way out of this scenario is to use a database which handles locking,delayed writes and concurrency for you. Thats why websites run off databases and not file systems.

Bingo! It's not really an x32 on x64 problem. It's an x32 in windows7 problem. there is only a finite number of addresses that can be gotten with a 32 bit number. Problem is, they are all towards the top end of the range since Win7 hogs most of the bottom. Without switching to X64. you will still be limited in the address space so 20 is probably the best you can hope for. The trick is, how to offset those addresses against the Windows7 OS to claw back some memory for your app. Try having a read of this. It works on Windows 7 (I believe and have been told, but never tried). where have I heard that before

Vartor provide a "Crypto Pack" which (IMHO) is well worth the $20 especially as it comes with full source. It has (amongst other things) AES.

Why not just use the "Deny Access" vi (should be in LV7.0 - under file IO>>advanced file functions).

How hard is it to tx data and power through metal? My mains plugs do it pretty well

If you are having difficulty with firefox. Open the image in a new tab before dragging to the desktop. It can be a bit of a pain in firefox. (it's even worse in chrome) You can tell it's a snippet because it has the hand,arrow and lv icon in the top left of the diagram image. It also has the labview version in the top right.

If you are using exploere, just drag the image from explorer to an empty diagram. If you are using firefox, drag it to your desktop then drag it from there to an empty diagram. VI snippits are png image files with the actual code embedded in the image. When you drag the png image to a diagram, labview will re-create the code.

Good choice. Just stick some length bits on the front (u64) and you are good to go.

Can't help with the problem. But maybe can explain how it is different It is a "plug-in" control and resides in the "\resource\PlugInControls" directory. As far as I'm aware, it is an undocumented interface allowing controls to be created from external DLLs and resources. I have a feeling it was the way NI was going for custom controls before they decided on Xcontrols.

Sorry to hear that dude. I'm in a slightly different position that I'm about to throw in the towel. But JKI seem to be sucking up any and all LV programmers. Maybe there's a chair there with your name on it already