Rolf Kalbermatter

How should that work? An exe build on Windows expects to run on Windows (or maybe Wine) and an exe built on Linux expects to run on Linux. Linux doesn't know how to load and run the Windows PE format that the LabVIEW exe stub is in, and Windows doesn't know how to run the elf startup stub that is in the LabVIEW for Linux executable. Executable Files are always specific to the platform they are created in, and can't be moved to a different machine architecture, independant if the the CPU type is the same. In the case of LabVIEW VIs (not included in an executable but run for instance through VI Server) a similar limitation applies. VIs will only run in the runtime engine for which they were compiled and since the runtime engine doesn't have a compiler included this means you need to have loaded and saved them the last time on the same platform as you want to run them in a runtime engine.

Are you really sure there will be always at least one object? Why not coarse the index to the lower and upper end instead of always setting them to 0 when out of bound? If obj/varCount is 0 you still will index the first element later on!!!!! Are you sure slaveInfo_->group is never a NULL pointer? And if that is the case, are you sure it points to a buffer long enough, that can be overwritten with your string? And the overwriting as well as the commented out code have another potential problem. Since the slaveinfo structure seems to be returned by the function and probably isn't allocated as you otherwise would need to deallocate it at the end, it is likely static memory or at least a static global pointer and messing around with its contents could then have fatal consequences for the driver implementation in the DLL. You don't need the + 1 since LabVIEW string handles don't need to be zero terminated and shouldn't contain a possible zero termination char in their length count. Many potential trouble and I'm sure there could be more as I do not know the entire API. The API structure is a very nasty implementation and IMHO worthless. This is fine for internal function parameters but not for an API that can be accessed by other units.

Copying kernel drivers to the system directory will do nothing for your target system. You also need to register such drivers at the Service Manager, in order for them to be loadable by Windows. And most likely you will also need to add additional registry values, for the Plug and Play system to associate your driver with a particular hardware resource.

In that case you are leaking that memory with every call???? A few more notes: You are indexing into the object and variable tables with passed in parameters without verifying that those indices are valid in the constraints of the provided data.

First I didn't even catch that you were not even allocating memory for the slaveInfo, etc. local variables. That is quite an error to do for a C programmer! It should have been the first thing to check before you even post! But I was really referring to the embedded string handles in the structures you pass from LabVIEW. Unless you go to the length to explicitly fill those elements with actual initialized arrays of sufficient length in the diagram, those string handles will be empty handles when arriving in your function, and an empty array in LabVIEW is simply a NULL handle for performance reasons. No use to allocate a handle (two pointers) that can only hold the 0 integer to indicate that no data follows. LabVIEW Handles are NOT simple memory pointers. They are really pointers to pointers to memory blocks AND need to be allocated and destroyed with LabVIEW memory manager function calls, as described in the External Code Reference Manual, since LabVIEW will use the same functions to handle those handles. If you just plainly go and use malloc(), you confuse the memory manager in very serious ways that will sooner than later result in unrecoverable errors. Look into NumericArrayResize(), which is the recommended way, or the low level functions DSNewHandle(), DSSetHandleSize(), etc. Instead of: size = strlen(slaveInfo_->group);memcpy(LStrBuf(*pSlaveInfo->group), slaveInfo_->group, size);LStrLen(*pSlaveInfo->group) = size; you will want to do something like: size = strlen(slaveInfo_->group);err = NumericArrayResize(uB, 1, (UHandle*)&pSlaveInfo->group, size);if (!err){ memcpy(LStrBuf(*pSlaveInfo->group), slaveInfo_->group, size); LStrLen(*pSlaveInfo->group) = size;} And a nitpick really but it's not a CIN. As far as I know the newest LabVIEW platform versions (64 bit Windows for instance) doesn't even support creating CINs. Instead you create a shared library (DLL) and import it using the Call Library Node (CLN) on all platforms.

What makes you think these handles have been allocated so you can simply access their data pointer to write data into?????

That is not control panel related. You will want to look for Twain control from within LabVIEW. There exist libraries, some commercial and I think at least one non-commercial to do that, but be warned: Twain is a recommended standard to the letter, meaning recommended is all there is. Every scanner supports whatever it feels like from that standard, and that is usually very little. It's sometimes a vabanque game how to get a scanner to work through Twain, yet any other way of accessing scanners (for instance DirectX) is usually even more problematic.

The internal MatchPattern function is regex similar but by far not as extensive. I haven't timed the MatchPattern with a normal PCRE call yet. Personally I think MatchPattern, while being a nice function, most likely isn't as optimized as PCRE but doing less and therefore being simpler it still likely does it's thing faster than PCRE. Since the MatchPattern function exists in LabVIEW since at least version 3 or 4, and since it would be way to tricky to develop a wrapper around PCRE to behave EXACTLY as the old Match Pattern function, I'm very sure it is still the old function. On the other hand I just recently run into a problem, where behaviour of Match Pattern was changed. First they changed the documentation in 8.2 and then they changed the functionality to match the documentation in 8.5!! It struck me as very sneaky.

What would be wrong with using Boolean logic (NOT, AND, OR) and ROTATE instead? There you have full control of signedness of numbers and that worked as far back as LabVIEW 2.x.And it's most likely magnitudes faster, since it can be all done inplace, translates typically directly into one or two assembly codes, and doesn't use variable size arrays at all.

Sorry, this method doesn't really exist as far as I know. The archive directory is embedded in the actual file stream and modifying it without modifying the entire file structure seems not very easy. The structure does allow adding new entries to the archive without complete rewrite of the archive, but deleting and modifying is another beast. I may have missed something but as far as I know using the same aproach as the ZLIB Delete File function is really the best there is.

I see why you think that, yet this tends to be rather static data, unless you happen to startup and exit lots of service enabled NI and LabVIEW software applications. So not really that exciting to watch

Actually a better fix is to apply the correct logic in ZLIB Store File.vi itself, since in there is already code to detect if the entry is a file or directory. I will look into this as soon as I have finished setting up the essential tools on my new machine, since the old machine is kind of dieing, I rather don't want to use it for any work anymore.

Actually a correction to my earlier post. The VI library mentioned does not allow to see all the registered services but instead you can enter in your prefered WebBrowser: http://localhost:3580/dumpinfo?

You could look into service names. The TCP and UDP functions in recent LabVIEW versions allow to wire a string to the port input which can define a service name. For server functionality this registers the service name with the dynamically allocated port number at the NI Service Locater service for that machine. For client functionality it queries the Service Locater for the port number for the specified service name. I saw in the LabVIEW 2010 configuration yesterday that you can specify a service name to be registered for the current LabVIEW instance and I'm sure that can be put into the executable configuration too. Not sure however how that works in combination with multiple instances of the VBAI since they all would use the same configuration file to startup. Also there is a VI library in vi.lib/Utility/ServLocater.llb that allows to interact with the service locater programmatically. It allows to query the service locater for all currently registered services, so you may be able to see if starting up multiple VBAI instances does register any service name and what pattern the service name would follow.

Font is not equal to font. You have so called bitmap fonts and true type fonts. Bitmapped fonts can only be displayed in the sizes that the font file contains specific bitmaps for. Maybe that Windows 7 in the user interface supports resampling them nowadays, not really sure about that, but the result is always suboptimal, with artefacts such as blurry edges. However most printers still don't know how to resize bitmap fonts, and I would be surprised if the Report Generation Toolkit even attempts to support that. Courier New is a true type font and those are defined in vectorized form and can therefore much more easily be resized, and Windows supported resizing them basically from the start when they introduced that feature in a similar way than Apple had decided to do already earlier. True Type fonts are really developed in cooperation with Apple and Adobe, and Microsoft took them over with some help of Adobe, not without making some minor modifications to the meaning of some of the parameters in the font file, so that a one to one copy wasn't possible.

A well, .Net. Always a possibility but annoying to use. In my searchs I have found that LabVIEW 3.x and 4.x did export a C manager function that would have allowed to do that in a CIN and after 5.0 with a Call Library Node but alas, the LabVIEW Gods at that time decided that this was an unneccessary private API and they removed it.

I assume you would want to display a selection box with all the possible fonts listed. And I have to inform you that despite very deep searching in the depths of LabVIEW's basement and attic, I have not found a way to get this information during runtime into an application. My detective work has been carried out 2 or so years ago, so there is a small change that 2009 or 2010 have some hidden possibility for this, but I somehow doubt it.

Well for fading you have to use alpha shading and alpha shading has the ostensible property of requiring the retransmission of the entire affected area with every step of the continuous shading effect. That is a lot of bitmap data! RDp or VNC or whatever similar functionality has a lot of optimization built in to reduce the amount of data that needs to be transmitted. I'm sure RDP transmits the actual GDI drawing commands rather than bitmap data whenever possible and when transmitting bitmap it most likely will optimize to only transmit the parts that change between picture changes. Yet with fading in EVERYTHING changes constantly!! Maybe they will at some point transmit the fading as a drawing primitive too, so the actual transmitted data is a lot less, but for now it is a bitmap transfer over and over again. And because it is a rather cosmetic only feature they sure won't declare it as top priority item as long as there are other areas that still need some improvement too.

Exactly and you made already the specific limitation when you said "in cartesian space". If that would be all that is possible then your squangle would be indeed very useless, but we can imagine, and some can even calculate in, very uncartesian spaces, so your squangle has indeed a valid place. My statement was also more meant to provoke than to state something I believe in. Altruisme as this guy interprets it is very specific and as Yair already pointed out he even seems to ignore one interpretation he brought up himself too. Your pleasure pain equation has a lot of merits and can explain a lot of different behaviors but it mostly ignores any of the indefinite possible reasons that some people have such an extraordinary pleasure pain equation in comparison to the big mass. There seems to be something that defines that equation and I highly doubt that it is just a random collection of brain cells .

So basically altruisme is a nothing, and should be deleted from our vocabulary, because it names something that according to this definition can't exist. Or we may have been looking at only one specific definition of altruisme so far, and are really missing the point altogether .

Now we all are curious, as to what you did, that it suddenly worked!

Well here are a few recent ones and also from February last year or therearound: http://forums.openg.org/index.php?showtopic=1997&view=findpost&p=5038 http://forums.openg.org/index.php?showtopic=1998&view=findpost&p=5039 http://forums.openg....findpost&p=3526 http://forums.openg....findpost&p=3527 http://forums.openg....findpost&p=5034 http://forums.openg....?showtopic=1104 (several by Retapitle) http://forums.openg....p?showtopic=994 (several by Retapitle) http://forums.openg....findpost&p=4851 http://forums.openg....p?showtopic=960 (last two posts) http://forums.openg....findpost&p=2816 http://forums.openg....findpost&p=3000 http://forums.openg....findpost&p=3008 http://forums.openg....findpost&p=3086 http://forums.openg....findpost&p=3118 http://forums.openg....findpost&p=5037 http://forums.openg....findpost&p=3010 http://forums.openg....findpost&p=3006 http://forums.openg....findpost&p=2998 http://forums.openg....findpost&p=2993 http://forums.openg....findpost&p=3063 http://forums.openg....findpost&p=4728 http://forums.openg....findpost&p=3067 http://forums.openg....findpost&p=2999 http://forums.openg....findpost&p=2996 http://forums.openg....findpost&p=3012 http://forums.openg....findpost&p=3004 http://forums.openg....findpost&p=2994 http://forums.openg....findpost&p=3002 http://forums.openg....findpost&p=3009 http://forums.openg....findpost&p=3078 http://forums.openg....findpost&p=3013 http://forums.openg....findpost&p=3001 http://forums.openg....findpost&p=3075 http://forums.openg.org/index.php?showtopic=1084&view=findpost&p=3011 http://forums.openg.org/index.php?showtopic=935&view=findpost&p=3003 I consider any nonsense post with non LabVIEW/NI /LAVA/ OpenG related links in the footer to be spam, even if the bot was smart enough to get some words from earlier posts and make it appear as if it is on topic. Usually a single post user account with useless message also looks to me like spam. A few of these could be maybe left, although I'm sure they were just test messages by the bot creator to see if it works. "Hello dude, this is great info" with only this single post for that account is simply useless. For obvious cases it would be good to disable the account too. A fairly good indication for these posts is also that it is usually a name with a 2 digit number appended.

Are you sure Windows is not blocking any network access for those applications? When first starting up you should have gotten a dialog asking you if the application is allowed to access the network. This dialog is easy to just click away! And the DLL running in the LabvIEW process will simply be treated as the LabVIEW process by the Windows firewall rules.

The only incompatibility I'm aware of for VI Server communication between different LabVIEW versions was I believe between 5.1 and 6.0 and also only from 5.1 server to 6.0 client, because they added some extra features to the initial connection establishment message.

It depends what you mean with performance. For me performance is mostly about speed and Deallocate Memory has only a negative effect on that if any at all. In most situations it does nothing nowadays. In earlier LabVIEW versions it was supposed to do some memory compacting but that had mostly bad slow downs as a result and helped little in squeezing out more memory from a machine. I believe Ben's statement that nowadays it will only affect claimed data chunks from VIs that have gone idle is correct.