Rolf Kalbermatter

QUOTE(Aristos Queue @ Jul 23 2007, 05:29 PM) This sentiment! Is that official NI policy now? Maybe it has come the time to consider for me if LabVIEW is still the tool I love to work with. Rolf Kalbermatter

QUOTE(Yuri33 @ Jul 22 2007, 10:36 PM) It's not undocumented. It is all (except the Library:LabVIEW trick in the Call Library Node) there in the External Code Reference Manual. Rolf Kalbermatter QUOTE(Aristos Queue @ Jul 22 2007, 11:38 PM) No, and using such callbacks is a trick we go to great lengths to prevent folks from doing. Yea, I figured some of the password protected VIs might use this and similar tricks ;-) But someone at NI must have forgotten that. There is or maybe used to be a code example on the Developer Exchange Site exactly with the MoveBlock function. So you hardly can call the Library:LabVIEW trick in the Call Library Node to be a well kept secret anymore. Rolf Kalbermatter

QUOTE(eaolson @ Jul 19 2007, 09:31 AM) I haven't thinkered with projects and such in VI server yet but this is just some of the basic understanding I have about LabVIEW VI server. The targets in a project should be more or less just like application references. And the way to open a VI in the context of an application reference is to pass that application reference to the Open VI Reference function. Have you tried to connect one of those target references to the Open VI Reference or maybe search for a property in the target reference that might return a real application reference? Rolf Kalbermatter

QUOTE(Aristos Queue @ Jul 20 2007, 02:42 PM) The way I do this is by calling the LabVIEW internal memory manager function MoveBlock through a Call Library Node. If you set the source parameter to be an uInt32 by value and the target parameter to be an uInt(x) by reference, and then also adjust the size parameter accordingly you get what is required. To call MoveBlock in LabVIEW you have to configure the Call Library Node as follows: Library Name: LabVIEW Calling Convention: Standard C Function Name: MoveBlock return value: void 1. param: source, uInt32 as Value 2. param: target, uIntxx as Pointer 3. param: size, int32 (number of bytes to copy) Advantage is that you do not need any Toolkits or plattform specific external libraries. Rolf Kalbermatter

QUOTE(Dirk J. @ Jul 20 2007, 09:03 AM) I think this has a memory leak. The IDList returned by SHBrowseForFolder is a memory buffer that should be freed with the (originally undocumented) ILFree function in shell32.dll. And for OSes before XP or 2000 this function was not exported by name, but only as ordinal number 155. A little known feature of the Call Library Node is that you can also reference functions that are exported by ordinal by entering the ordinal number as function name. LabVIEW seems to attempt to convert function names that only consist of numbers into an ordinal and try to load the function as such. Rolf Kalbermatter

QUOTE(Gary Rubin @ Jul 18 2007, 04:11 PM) Yes, the rules if LabVIEW does a data copy are mostly tied to the functions the wire runs to and especially if a wire has branching built in. And here multithreading might get in the place sometimes. When a wire branches, LabVIEW tries to execute functions that only read the data but don't reuse them further or create a complete copy anyhow before functions that could reuse the buffer. In that context subVIs are always considered as a potential consumer of a buffer. And now if you have multithreading in place LabVIEW might get in a difficult sitution: Serialize the code to execute non consuming nodes first or allow simultanous execution that requires a data copy in any case. I would opt myself for the first case as it should probably in most but the simplest cases where only skalars are involved be the more efficient solution. Rolf Kalbermatter

QUOTE(tcplomp @ Jul 18 2007, 04:34 AM) The http://www.vartortech.com/visecurity/cryptg.html' target="_blank">CryptoG Toolkit contains amongst many encryption and hash algorithmes a Random Number Generator and based on that a VI to create GUIDs. All these functions are fully native G code and tehrefore completely plattform independant. It's cost is nothing that should prevent you using it and I can really recommend it. Rolf Kalbermatter

QUOTE(Neville D @ Jul 13 2007, 10:55 AM) The TCP functions will return errors if no network card or at least a TCP/IP adapter (modem, broadband or whatever) is present in the system to which the TCP/IP socket layer can bind to or if those adapters are all disabled. Though I wonder if there still exist PCs without a network interface. Rolf Kalbermatter

QUOTE(Karissap @ Jul 12 2007, 11:39 PM) And it is likely to not work as desired in an executable. Rolf Kalbermatter

QUOTE(Tomi Maila @ Jul 11 2007, 02:11 PM) While in theory your conerns could be right they don't have to be for two reasons. 1) As long as you do nothing with a wire (and data dependency can ensure a variable stays put in memory until after a certain point) LabVIEW does not deallocate or move it. In fact all diagram data (except paths) are stored as DS (Data Storage) memory contrary to AZ (Application Zone) memory. The distinctions (although I believe in practice this makes no difference on most modern platforms anymore as the memory virtualization of modern 32bit CPUs completely hides the physical memory management of the CPU from all applications) is that AZ memory handles can be locked but don't need to be while DS memory handles always are locked. A locked handle means that the memory manager will never move around your memory block while you do other things in LabVIEW, unless you explicitedly use memory manager functions to deallocate or resize such a handle. Pointers are by their nature non relocatable unless explicitedly reallocated. 2) The memory manager has some very powerful functions that can directly move between pointers and handles and that ensure that the operation is properly protected in the context of the LabVIEW execution system. But even without this, as long as you make sure that no other LabVIEW functions can concurrently operate on a handle whose pointer you treat with your direct DLL magic functions, you can be sure to be safe. And by the way this is why LabVIEW has to and does make data copies on branching wires when more than one function can possibly modify that data. Rolf Kalbermatter

QUOTE(polyplay @ Jul 9 2007, 04:11 AM) If your actual C code header file is really as you show in your text file you might have a serious problem here. typedef struct { unsigned int LINMode; int baud rate; < this is definitely not valid C syntax. unsigned int LINVersion; unsigned int reserved; } XLlinStatPar; XLstatus xlLinSetChannelParams (XLportHandle portHandle, XLaccess accessMask, XLlinStatPar statPar); What LabVIEW will assume for structure parameters is: XLstatus xlLinSetChannelParams (XLportHandle portHandle, XLaccess accessMask, XLlinStatPar *statPar); passing the structure by pointer. I'm not aware that this can be done otherwise so maybe the C compiler will automatically make this parameter passed by pointer but that is beyond my C detail knowledge. Rolf Kalbermatter

QUOTE(Yuri33 @ Jul 8 2007, 11:46 PM) A less costly and also platform independant way is to use a Call Library Node to allocate memory areas by calling into LabVIEW itself. Setting the library name to LabVIEW you can call all the exported LabVIEW manager functions that are documented in the External Code Reference Manual and that includes the LabVIEW memory manager that can do all this. Make sure to use C calling convention as that is what LabVIEW exports its manager functions as, and obviously configure the rest of the Call Library Node according to the documentation for the function you want to call. Advantage is you don't need an (expensive) Toolkit installed and if you ever happen to have to move these functions to another LabVIEW platform this part will simply continue to work (the DLL part itself obviously not . Don't forget to deallocate the memory poiunters after use obviously as otherwise you create memory leaks. Rolf Kalbermatter

QUOTE(Yuri33 @ Jul 5 2007, 10:52 PM) IMAQ AVI file reference is not a proper LabVIEW refnum, but a private implementation to the IMAQ AVI library. So the Not A Refnum prmitive can't work there as it is strictly always not a valid LabVIEW refnum. What you can do is either try to typecast the refnum into an int32 and if it is not 0 then assume it is valid or probably even more safe use the IMAQ AVI Get Info function. If it returns no error then it is definitely a valid refnum. Of course the issue about why you would need to find out after the fact if it is a valid refnum does hint that you probably do not do proper error handling of the Create or Open function. Rolf Kalbermatter

QUOTE(robijn @ Jul 4 2007, 10:44 AM) I was pretty sure that LabVIEW terminated strings on return on the first NULL character already in LabVIEW 7 and I think even in LabVIEW 6. I did rely in 6.x several times on that, so not sure why you would see something else. If that is not desired you need to use byte arrays. Rolf Kalbermatter

QUOTE(PeterB @ Jul 4 2007, 07:50 AM) You don't! LabVIEW can NOT do anything with lib and obj files. That is for C compilers only and even then you have to have lib and obj files that are compatible for your C compiler, eg. meaning they should have been created by the C compiler you want to use them with too. You can't create a LabVIEW DLL and hope that LabVIEW will link to your lib file magically. A LabVIEW DLL is really a LabVIEW LLB with very small exported C wrappers around those VIs inside the LLB. There is no way you can influence the C wrapper generation made through the LabWindows CVI runtime engine to somehow include your lib file and even if you could it wouldn't help either, as the wrapper code generation does not know how to link to other lib files than what is necessary to wrap the VIs such that they can be called as a DLL export function. If this lib file is only an import library to the actual functionallity in a DLL then you could instead link to that DLL through the Call Library Node. Otherwise there will be no way around creating some C code to be put in a DLL and that can be called by LabVIEW that links with your lib file. In that case you need to create a DLL in Visual C, that you can call from LabVIEW and you want to include that lib file into that Visual C DLL project. I hope I didn't confuse more than help but it's simple! If the actual functionality of your lib file is not located in a DLL file for which you have documentation and the API interface, then you WILL have to create a C DLL first. Ok I reread the first post once more and I see that you want to create a DLL to be integrated in VisSim and that the DLL needs to link to vissim32.lib. This can't work without Visual C. In fact their statement that any environment that can create DLLs should work is mostly wrong. Besides Visual C there is only LabWindows CVI and proabably Borland C that can directly link with vissim32.lib. lib and obj files are binary files that can come in many flavors and Visual C will generate and require so called COFF format, while Borland will generate and prefer OMF format. LabWindows CVI used to support both formats for generation and linking but you needed to decide whith format you wanted during installation. LabVIEW can not generate obj files. What it can and does do is generating Visual C compatible import libraries for the LabVIEW generated DLLs. So what you can do if you need to generate Vissim callable DLLs that incorporate LabVIEW code is to generate the LabVIEW DLL and then generate another C DLL that also includes the lib file for vissim32.lib and your LabVIEW DLL import lib file. Rolf Kalbermatter

QUOTE(PeterB @ Jul 3 2007, 11:49 PM) Well if you create a DLL you always link with lib and/or obj files unless you never use any library functions, be it LabVIEW External Code functions, C runtime functions, or Windows API functions. But in Visual C you don't need to specify the C runtime library and Windows API import library specifically since most of them are added by default to a project and the Visual C linker picks from them whatever he needs. An obj file is the compiled form of a single .c or similar file and a lib file is just a collection of several obj files. EXEs and DLLs are the combination of all obj and lib files with some extra startup stub and possibly resources and other custom stuff put into. Basically you want to add your custom library file to your project somehow. You can do this by adding it explicitedly to the files that your project consists of, or in the project settings add the name of the library under Linker Settings and also provide a path to the directory where Visual C can find that library. Rolf Kalbermatter

QUOTE(communityguy @ Jun 29 2007, 03:27 PM) Actually it's more something like LabVIEW 5 or 6 . But it could have been BMP only (PICT etc on Mac) back then. Rolf Kalbermatter

QUOTE(ZZZZZZ @ Jun 29 2007, 02:16 PM) There are only so many TCP-IP ports but each server/service that needs to be IPC accessible needs to have one. Now NI can't go and register 200 well known IP ports for itself as that would not be tolerated by others nor would it be possible at all. So NI, and MS LM etc does the same, deviced a Service Locator. All this service does is listening on a well known port for service registrations with service name and not well known port number and then other applications/services (LabVIEW, online HTML help, Time Synchronization Service, Domain Security Service, Logos data protocol which I think is the base for Data Socket and Shared Variables, etc) can ask this service locater for the not well known port number of another service. On Windows this service locater is a native executable installed as service, on other platforms it used to be a VI based TCP IP server. Rolf Kalbermatter

QUOTE(vinamra @ Jun 28 2007, 10:44 PM) I would say you have to ask the guys from Girder. LabVIEW can do just about anything you could do in Visual Basic or similar and a lot more so ask them if you can control their stuff in VB, if they haven't heard of LabVIEW. If they say it can then ask them for examples. I would guess that the Girder package might have an ActiveX Automation interface somehow that you could use. As to the hardware it does not say if the IR Detector will be installed as a virtual COM port. So I have a hunch that it isn't and you will need to get some API (DLL or raw USB protocol stream) in order to control that device directly from within LabVIEW. Not sure what you could gain with that as you would still have to know about the data format of the different IR commands too, which I suppose are manyfold depending on the remote control manufacturer. Rolf Kalbermatter

QUOTE(orko @ Jun 27 2007, 06:44 PM) Each wire individually doesn't sound intuitive to me. Usually every user action is considered an Undo Transaction and selecting your wiring cleaner tool in the menu would seem to me one single user action. Imagine your tool doing 500 wire modifications and then the user realizes he wants to undo the operation just before he selected your tool. Ouch!!!!!! Rolf Kalbermatter

QUOTE(orko @ Jun 27 2007, 04:06 PM) Have you tried these? Rolf Kalbermatter

QUOTE(yen @ Jun 26 2007, 02:35 PM) Nice to see you finally :-) A big mystery lifted and now we can all go back to our work and finally continue to write great programs. You did create a big enigma over at the dark side. And it was fun to read those that were mulling over what sex this overactive forum member might be. Unfortunately I won't make it to NI Week this year but have fun there. Shouldn't really be to hard with all those people from here and other LabVIEW related places. Rolf Kalbermatter

QUOTE(Sherif @ Jun 26 2007, 10:05 AM) Well that is so true for some people! :-) Rolf Kalbermatter

QUOTE(Nullllll @ Jun 24 2007, 07:07 AM) <br /><br /><br />Has the door of your home any mechanisme to control it at all???? I mean this is the most basic question and I haven't seen mentioning you anything in detail about that fact yet. You ask about if you should use a motor, yes and that tells me it hasn't such a mechanisme built in so maybe you should try to contact the tech workshop at your place first and talk with them about the mechanical construction to allow your door to be opened at all. Then when they have given you a solution to open that door somehow we can talk further about how to control it from LabVIEW. Rolf Kalbermatter

QUOTE(Aristos Queue @ Jun 22 2007, 08:18 PM) Actually there is a primitive somewhere that returns the file name for a given file refnum. So it would be possible to find out the file name and open a new refnum to that file, provided the access and deny rights from the initial open allow for that. Rolf Kalbermatter