Rolf Kalbermatter

Receiving email is done with the POP3 protocol (or some more advanced one). There authentification is always necessary since you can look into the mail box of a person. To send emails you are using an entirely different protocol called SMTP. SMTP is completely independant of POP3 and had traditionally no need for authentification before the sh*theads of spammers started to poisen email.I'm not sure where you got the POP3 VIs though, maybe the Internet Toolkit or OpenG, because LabVIEW does NOT come with POP3 VIs out of the box. The LabVIEW email VIs implement the SMTP protocol but without support for authentification. But since you get error 62 I think it is likely that you don't even get the the point where authentification is required but rather that a firewall or something like that is dropping your connection immediately. This is: 1) A problem most likely entirely out of control of LabVIEW, eg. your network setup. 2) Something you will need to investigate by debugging into the LabVIEW VIs (single step mode, etc. etc.) 3) By going into the email subVIs you can also see what the server is answering if any and only with that detailed information is any chance that someone else here can help you. Rolf Kalbermatter

What I did once in an application was using the enclosed VI. Use the alias array to initialize the strings of a Ring Control. Then use the selection of the Ring Control to index into the adress string array and pass this to the VISA Open. Rolf Kalbermatter Download File:post-349-1140556159.vi

Considering that the SMTP VIs are with full source code you could certainly go a little deeper and single step into them to see what the problem is. The SMTP VIs as they come with LabVIEW 7.x and higher work very good but have a few limitations. First they have no support for authentification. If your SMTP server requires authentification then you will have to look for alternatives. Second they can NOT make a hole into your firewall on their own, both on your computer nor some gateway on the way to your SMTP server. You will have to configure the firewall(s) to allow the SMTP traffic to go through. Sending SMSs is a completely different story. You can directly communicate with the GSM modem through VISA and the serial port but not every GSM modem has exactly the same command set. Also to get a reliable communication with a GSM modem that does always work independant of the initial state of the modem is quite some work. I have done it in an alarming and messaging application for Wismo GSM chip based modems (Wavecom and Maestro) and it wasn't trivial. Our company also sells a Toolkit to talk to these modems http://www.citengineering.com/pagesEN/products/sms.aspx Another possibility is to buy some ready to run SMS application and install it and interface to it through ActiveX, TCP/IP or whatever it supports. If your messaging and alarming should be reliable writing your own solution won't be a very straightforward and fast way to do it. Rolf Kalbermatter

But LLBs already used a moderate compression algorithme. Not as good as zlib but still around 15 - 30%. Rolf Kalbermatter

You probably tried to do some fancy datatype here. Just treat the handle as uInt32. In the Logon function this parameter is passed as Pointer to Value. In the CloseHandle case just as Value only since it is not a parameter by reference here. Rolf Kalbermatter

This was an addition to LabVIEW 6.1 exactly because you couldn't rename a Tab in a TabControl. Making a TabControl behave like a RingControl instead was no option as that would have caused problems with backwards compatibility and in fact removed some functionality and ease of use from the TabControl. Rolf Kalbermatter

Hey, don't tell me you have white hair! In my age that is something that comes to men naturally but for you I had thought that will take some more time :-) Good luck and may IVision still bring you some compensation for whatever you've put into it. Rolf Kalbermatter

First: GetIndirectFunctionHandle and friends were only meant and available for LabVIEW for Windows 3.1. Second: In order to call a function over a pointer variable, this pointer variable must be properly typed either through the declaration itself or a typecast at the point of call. Otherwise the C compiler can't know how to pass the parameters and what to expect as return value. if (!(UsernameCStr == (char *)DSNewPtr(*Username)+1)) {cinErr = mFullErr; goto out; } will allocate not what you think it does. It will use the pointer value in the handle as length indicator and attempt to allocate potentially a huge amount of memory running out of memory quite soon. You should make this read if (!(UsernameCStr == (char *)DSNewPtr(LStrLen(*Username))+1)) {cinErr = mFullErr; goto out; } and even better would be to allocate a cleared memory area with DSNewPClr(). Instead configuring a CallLibraryNode with advapi32.dll, LogonUserA, stdcall calling convention, the string parameters as C string pointers and the two constants as uInt32 and the last one as an uInt32 passed as pointer, simply should work fine. Last but not least you will leak a handle here with LogonUser returning the phToken that never gets closed. Rolf Kalbermatter Download File:post-349-1140011772.vi

I didn't now that you didn't know about LabSQL then. To me it had seemed the most efficient way to build on LabSQL and improve and extend on that one, seeing that you have mostly the same licensing philosophy as the original author of LabSQL. Would have saved you quite some time ;-). And improving and extending an existing Toolkit probably just as much gets you into learning the basics of it. Rolf Kalbermatter Why should anybody want to do that? Database Access over ADO works well, is supported on many more machines than .Net (.Net only working under Windows 2000 after installing an update) and most database drivers are either ADO or ODBC based. Using .Net would just add an extra complexity level to the already involved picture of ODBC driver->ODBC manager->ADO-ODBC gateway->ADO system->ADO->ActiveX interface. I can think of many better ways to spend CPU cycles, memory, and HD space. Rolf Kalbermatter

I can think of a few not so complicated runtime checks that would disallow the workaround found by Stan and if I can think of it, the guys at NI can for sure as well. If they find it necessary to worry about that one, I'm however not sure. Rolf Kalbermatter

While the registry might hold this number somewhere it is not terribly difficult to hook the registry access and return to a specific applciation different information than to the rest of the system. It definitely gives an attacker an extra angle to get in, and if you consider HD serial numbers not secure enough you must envision a dedicated hacker and not just the joe average user that knows little more than how to start an installer. Of course you can even fool a tool that gets the information directly from the BIOs but that really requires some assembly and protected mode knowledge, although that knowledge is not something strange among real hackers. Rolf Kalbermatter

Id2x I have just a question? Isn't LabSQL (and incidentially the Database Connectiivity Toolkit from NI) not also using ADO? If so what does your solution add to this? Rolf Kalbermatter

What has this to do with the original post? Thread hijacking is not nice! Rolf Kalbermatter

I for one don't but I happen to have played with the functions in LabVIEW 7.1 recently and probably come across a possibility similar to what Stanislaw has done in his other thread where he handed us the ladder to reach the toys, NI in its universal wisdom had put on a very high shelf. But I also can envision that NI might try to close that loop hole too, putting even the execution of certain nodes behind the licensing. Rolf Kalbermatter

Yes, scripting is now not anymore controlled with an ini file setting, but through the license manager. (In fact it seems LabVIEW still wants to have an ini file setting but it will only check this setting after you have installed a valid scripting license, and no it is not the same ini file setting as in the past :-( Rolf Kalbermatter

The MAX API is private and undocumented. Nobody outside of NI can write drivers that integrate with MAX directly (aside from the standard OS drivers such as COMM for serial ports) that integrate in MAX. I doubt that there are many manufactuerers that have such an integrated and feature rich configuration interface for thier hardware as what you get with MAX. Rolf Kalbermatter

Not exatly sure as it is a long time ago when I investigated scripting. But if my memory serves right you will have to walk through the rather large LabVIEW object hierarchy to get to the wire in question and then using a Method (or was it a Property) node you can set the breakpoint on that wire. As to how to walk the object hierarchy of a VI, there have been several examples here on Lava but it is a pain indeed. The problem is, I can not see another possibility to implement this object model in a way that would be much easier to walk and understand without loosing tons and tons of possibilities. Personally I think this is the main reason NI has not decided to make this feature available to outside people since they can envision a load of support requests if that feature gets made public. Rolf Kalbermatter

I'm posing a possible explanation to the problem. It seems that your error message contains a path that is only partly complete (breaking at the space in National Instruments). Obviously at some place the path construction is not done correctly and if you pass a path to a command line tool containing spaces and that path is not embedded in double quotes the command line tool will see the path as multiple command line arguments resulting in each argument to be an invalid path. I wasn't saying that this is something you did wrong but that it is something with lvmetadiff and or other tools involved. Since they are however all Open Source and available in source code there is no reason why you shouldn't be able to go and try to fix the problem for yourself. Rolf Kalbermatter

This won't work. The CIN node or shared library is still running in the application context and as such has no direct access to the protected kernel resources to whom the Port IO adresses belong. You have to extend your kernel itself to allow port access either by a port IO kernel driver that translates your port access requests to the actual hardware access on behalf of your application or by an expansion to the kernel with a system call to manipulate the IO permission map. In the first case you call your device driver and pass it the IO adress, access mode and data and it does then do the actual port read or write for you and in the second case you do a system call to that new kernel function to tell it to modify the port IO permission map for your process to allow direct access to specific IO adresses from your application process. Rolf Kalbermatter

An IMAQ runtime is

I'm afraid you can't. An LStrHandle is a special LabVIEW datatype and there exists no direct .Net equivalent for it. As you can see in extcode.h, it is a pointer to a pointer to an int32 followed by the actual (non-unicode) character string. As such it is not even directly a long Pascal string (although with a pointer to such a beast you could simulate it) but I doubt that .Net even would support that one. Rolf Kalbermatter

A C compiler does just that. You use the sizeof() keyword for this and that will calculate the compile time size of any datatype including structures and use that value in the compiled code. LabVIEW obviously does not have C parsing capabilities so can't do anything for you with that header file. Rolf Kalbermatter

LabVIEW scripting in LabVIEW 8 is put behind the license manager. There is currently no way to get LabVIEW scripting to work in LabVIEW 8 except for NI guys. Rolf Kalbermatter

Embedded space problems!! The path to the files should be enclosed in double quotes. Now where is the problem? lvdiff? shell extension configuration?? Rolf Kalbermatter

I'm not aware of videocap but instead avicap. If you mean that you are probably using the WebCam library from Pete Parente. Avicap is an old API from Windows 3.1 days that is based on Video for Windows (and a vfwwdm driver allows it to also access WDM drivers indirectly) but avicap has no provisions for really configuring the video device as there wasn't much to configure programmatically back in those days where it was common to have to set jumpers on the board for a lot of things. The only interface that allows real configuration programmatically is the DirectX/WDM based interface and your best bet is to use an ActiveX interface for this either buy it or roll your own. You might also want to look into Irene He's IVision library, but that is also not really free of charge although a little cheaper than IMAQ Vision. Rolf Kalbermatter