Rolf Kalbermatter

QUOTE (jebus @ Jun 18 2008, 11:54 PM) And now with everybody knowing that this server is an open proxy it will either be changed to require login soon or it will end up on every single blacklist on this planet, resulting in you not being able to send your LabVIEW mail to many recipients, since they will often use those blacklists to filter out incoming mail for spam. I know our servers are configured to filter out mail originating from IP adresses on those blacklists. Much easier and better would have been to point your local email server to proxy for you to your ISP. Your email server should certainly be able to use proper authentification to contact your ISP SMTP server so that you have a hopefully firewalled to the internet, open SMTP server on your local network that will allow your LabVIEW program to contact it without authentification and will take care of the authentification towards the ISP instead. Rolf Kalbermatter

QUOTE (menghuihantang @ Jun 17 2008, 03:55 PM) Jason's solution is the best of course. Another more quick and dirty solution is to use the timeout input to the Listen VI. Set it to a value that is not to slow for user interaction (250ms is usually quite small enough). Of course the listen node then wil return if there has a connection arrived AND also if the timeout has expired and in the second case accordingly return a timeout error which you have to filter and ignore and go back to listening again. But as mentioned, Jason's solution is the more robust one and definitly has my preference by far. Rolf Kalbermatter

QUOTE (ned @ Jun 12 2008, 12:57 PM) Your last suggestion is the only real solution. ActiveX has in theory the possibility for a library to be invoked in various modes. One is out of process invokation in which case the ActiveX object is instantiated in its own server process and communicates through RPC and a proxy library with the client. However almost no ActiveX component supports this mode and they are almost all in-process servers. This means they run inside the process that is instantiating them and therefore can affect and also take down that host process. I'm not even sure if LabVIEW does support out of process instantiation of ActiveX components. If it does it won't be a well tested scenario since there are so few ActiveX components that would even support that. Rolf Kalbermatter

QUOTE (PhattieM @ Jun 12 2008, 11:02 AM) This should be fairly simple. For every function in the object library that you want to be available in LabVIEW through a Call Library Node you would have to write a small wrapper. Something like this: Original function as exported from the lib: int MyFunction(int param1, int param2); Your new function: __declspec(dllexport) int LV_Myfunction(int param1, int param2) { return MyFunction(param1, param2); } Then compile it into a DLL, linking this with your object library. Possibly you could maybe suffice with a modified header file in a DLL project without any other source files where you add the __declspec(dllexport) in front of each function and simply link in the object library but I never tried that. If you want to persuade the Python solution you could look at LabPython. It is on sourceforge. Rolf Kalbermatter

QUOTE (one734 @ Jun 12 2008, 04:39 AM) There is enough discussion about this. All in all this is a very clear case where trying to do everything in LabVIEW is a masochistic exercise at best. Go and write a wrapper DLL that wraps the HALCON DLL API and provides a more LabVIEW freindly interface. If you want to pass in LabVIEW native data like string or array handles you can use the LabVIEW memory manager functions as described in the External Code Reference Manual to prepare, resize, allocate, deallocate, etc. the memory blocks necessary. And by the way some good C programming basis is not only beneficial but in fact an absolute requirement to get a result that would be usuable in a real application. That is even more true so if you would want to try to avoid the wrapper DLL since you will have to deal with things in LabVIEW that are normally taken care of by the C compiler. Rolf Kalbermatter

QUOTE (menghuihantang @ Jun 11 2008, 12:36 PM) Either I'm misunderstanding you or you are misunderstanding the event handling here. The data from the Event trigger is actually passed into the VI in "Event Data". If this parameter is by reference and the event is meant to pass some data back to the trigger function I would suppose your callback VI needing to supply this data back in "Event Data Out". There is no way you will ever see data from the event trigger source in "Event Data Out" since this is an indicator and meant to pass data back to the caller. Could it be that you did not understand that the Callback VI is invoked by the external event trigger but rather think it to be the event trigger itself? (Which would not make any sense by the way). Rolf Kalbermatter

QUOTE (PJM_labview @ Jun 13 2008, 02:22 PM) First LabVIEW does not even get informed about user events that happen outside of it's own windows. There are some system events like shutdown, power management and such that get passed to all applcations but most other events like keyboard, mouse, etc. are only passed to the window that has currently the focus. That is an OS limitation and in fact a good one since otherwise user event handling would get SOOOOOOOOOO slow (and a misbehaving application could block the entire system from working properly). That said one can register hooks in the form of C callback functions into the OS for particular types of events. They can be usually global but not always, or application specific. Windows is very clear about installing global event hooks: DON'T DO IT for released code and that would include LabVIEW. It's a sure way of degrading system performance and once every application would start doing it Windows would be sluggish to the point of uselessness (Some would argue that it is that already without global hooks). So if you want such hooks you probably will have to bite the bullet and write some external code in C (and make sure to not include such code in production quality software). Also it still wouldn't help for Drag & Drop. A target is only informed about a Drag & Drop operation at the moment of entering its window in a D&D transaction. This event can be used to query the available data formats and change the cursor to indicate acceptance or refusal of the D&D application. However this interface is rather complex to use and that is probably the reason why external D&D support hasn't yet been integrated into LabVIEW D&D. I'm sure there are myriads of difficulties and complexies that make offering this interface in LabVIEW very hard to make user friendly (I mean here LabVIEW programmer friendly). To make things worse, D&D is implemented using COM and not routed through the Windows message queue. Rolf Kalbermatter

QUOTE (marp84 @ Jun 6 2008, 04:16 PM) Sorry! I'm not going to open Windows bitmap files (.BMP). Saving them as JPG would at least shorten the download time considerably and wouldn't be a lot more work on your side. Rolf Kalbermatter

QUOTE (Andre Tomaz @ Jun 6 2008, 11:15 AM) It's going directly to the ODBC API. More precisely it is for the most part relying on ODBC 2.5 features only since I started that work back in 1996 and improved on it since. QUOTE I am having a lot of trouble with ADO. I think there is a memory leak in the MS ADODB component... -I have tried many things, but all solutions using ADO seem to show the same problem. Have you ever experienced anything like this? Do you plan to put your ODBC library avaliable for other users? No I never really used ADO based libraries, not the NI SQL Toolkit, nor the LabSQL Toolkit, nor the IB Berger ADO Toolkit or the T&M Database Toolkit. There seem to be some problems with ActiveX references not always being closed in some of those toolkits. But I have not really used them so I can't give more details. My driver being for a large part a DLL/shared library also has the potential of memory leaks although I believe I got it to the point where memory leaks should not happen anymore. About putting it up for others to use, I've thought several times about it but decided for a number of reasons against it. To name a few reasons: - It works for me but its documentation sucks and its features have by far not all been tested and also not with many ODBC drivers and it's likely to fail with some ODBC drivers since ODBC is more like a RECOMMENDED standard than a real standard. - Documenting and maintaining it would cost a lot of time but I have not figured out a workable way to cover for the cost of that. Selling Toolkits does not work, selling support for it is also more or less unworkable. - Its DLL/shared library is rather advanced and I do not want to open source it. Given these reasons it simply is a lot more cost effective to not spend more time for that than is necessary for my own use. That cost can be charged to specific projects, public use as Toolkit basically not. Rolf Kalbermatter

QUOTE (neB @ Jun 6 2008, 07:53 AM) You are of course right. Creation of any refnumed objects in LabVIEW has to be done in the context of a VI hierarchy that does not go idle for the life time of the refnum. In this case the best thing would be to have a deamon running in the background that gets instantiated if necessary by the remote queue VIs and takes care of queue creation on behalf of the those remote queue VIs. Rolf Kalbermatter

QUOTE (crelf @ Jun 6 2008, 07:26 AM) Actually I think the story behind it is a little different. First IMAQ Vision was indeed bought from Graftek and was at that time called Concept V.I. However I'm pretty sure NI acquired all rights on Concept V.I. and consequently does not pay royalities to Graftek. They also bought at a later time ViTA from them and added it to IMAQ Vision and also another software that was the base for IMAQ Vision Builder. NI-IMAQ, the traditional driver for NI image acquisition boards is free to use (and makes only sense with NI boards). IMAQdx the new style API to control NI image acquisition boards seems to require a license activation which may or may not come with the NI image acquisition board. Not sure about this last part. Rolf Kalbermatter

QUOTE (ragglefrock @ Jun 1 2008, 06:18 PM) Actually I think the Call By Reference call will handle arbitration nicely so if you can provide VIs with atomic access to a particular queue you should be fine. Rolf Kalbermatter

QUOTE (Neville D @ Jun 5 2008, 12:32 PM) It's how Vision software generally works. And after all it is some serious engineering to do Vision software so I can understand that the vendors want to get some form of return of investment. You could argument that LabVIEW is probably just as expensive to develop and its licensing is quite a bit simpler since it does not require seperate runtime licenses. But it's not the same industry really, with LabVIEW competing with traditional development environments like Visual Studio, Borland, etc, that do usually not require runtime licenses and we've been through that already in the past when NI tried to get runtime licenses for build LabVIEW executables. Rolf Kalbermatter

QUOTE (jcryan @ Jun 5 2008, 02:08 PM) I don't have such a camera and couldn't do it. Maybe the original poster did something but my experience with this is that most do not bother with the complicacies this causes. Rolf Kalbermatter

QUOTE (jebus @ Jun 5 2008, 03:26 AM) Jim answered about gmail. That about your ISP I'm not sure. For some reasons the server considers your attempt to send data as Junk Mail. Why that would be I have no idea. Technically there seems no reason to believe that the communication did not proceed right. Maybe that you should use a FROM: address in your attempt??? Maybe cableonline requires a specific procedure??? I'm afraid you will have to ask there about this, as painful it might be to get a support person from an ISP that even understands what you are talking about. Rolf Kalbermatter

QUOTE (jdunham @ Jun 4 2008, 07:57 PM) You are so right! Sorry QUOTE It would be great if you could set a string control (especially if input is limited to a single line) to scale with the font the way the numerics od. Thought about that also at some point but was to lazy to make a product suggestion. Rolf Kalbermatter

QUOTE (jebus @ Jun 3 2008, 09:58 PM) The SMTP email VIS do not implement authentification. As far as I know you can't use gmail (and just about any other email provider accessible over public internet) without authentification. You could however use your ISPs SMTP server instead (if you are on a broadband connection) or your companies email server (if you are on a company internal network). Those servers usually allow unauthentificated SMTP access since you access them from the internal network and therefore should be considered trustable. Rolf Kalbermatter

QUOTE (BrokenArrow @ Jun 3 2008, 09:11 AM) Actually it probably depends on the chosen font. Unless you use a TrueType (TT) font Windows will not scale fonts smoothly in one step increments. Those non TT fonts are not defined by glyphs but by bitmaps instead and they do only exist in a discrete amount of sizes. Windows does not attempt to scale bitmap fonts in one step increments because the result would be VERY bad looking. Real TT fonts allow almost seemless scaling to just about any size. LabVIEW does not have anything to say about that. It specifies the Font Name and the size and attributes and Windows does whatever it thinks it can do. LabVIEW has virtually no further control about that other than querying the size of the resulting font to adapt its numeric controls to it. QUOTE (jdunham @ Jun 3 2008, 03:47 PM) I looked at your image. I think the fonts are exactly the same, but they are rendered to a different pixel size in Vista than they were in XP. Remember that integers can only be one line, so labview will always resize the numeric for the specific font size. For strings, the control itself does not resize automatically. As a test, select all of those objects and change the font size to 8 or 9 or something. The numeric array will get a lot smaller, but the string arrays won't change, even though their fonts do. No! the problem is that numeric controls adapt their height to the font applied to the number inside wheras strings do not do that. This is in fact a copying of Windows control behaviour which NI better would have left out IMHO. You can also see that you can not resize numerics in height but only in length whereas strings can be sized to any height independant of the font they display in. Rolf Kalbermatter

QUOTE (crelf @ Jun 2 2008, 03:59 PM) Nope that window does not have any title. Rolf Kalbermatter

QUOTE (normandinf @ Jun 2 2008, 04:46 PM) Works nice! But only as long as there is one single ActiveX/.Net control on the panel. Rolf Kalbermatter

QUOTE (Tomi Maila @ May 29 2008, 07:27 AM) First saying that LabVIEW does not have a memory manager is a bit of a stretch. It's not a garbage collector memory manager like Java has and consequently requires the application to be secure about memory allocation/deallocation to avoid memory leaks during operation but there is nevertheless a layer between LabVIEW and the crt memory allocation routines that I would consider a sort of memory manager. It used to be a lot smarter in old days with help of a memory allocator called Great Circle to compensate for the inadeqacies of what Windows 3.1 could provide for memory management. The behaviour you see is quite likely a feature. I come to this conclusion because of two reasons. First it's behaviour is similar to how LabVIEW uses memory for data buffers when calling subVIs. This memory is also recycled and often not really deallocated. Also the fact that Request Deallocation cleans it up would definitly speak against a leak. Leaks are memory whose reference the application has lost for some reason. This seems not to be the reason here. The Variant most likely keeps the array handle and on negative resizing simply adjusts the dimSize without invoking the memory manager layer to resize that handle. An interesting test would be to see what happens if the small variant does not contain 0 elements but a few instead. Because I could imagine that on an incoming 0 size (or maybe very small size array) the existing internal buffer is reused (with copying of the incoming data to the internal buffer for small sizes) but on larger sized arrays the incoming handle is used instead and the internal handle gets really deallocated. Rolf Kalbermatter

QUOTE (BrokenArrow @ May 27 2008, 11:46 AM) Sorry haven't used it but MAX definitly won't see those boards at all. MAX is an NI application and supports NI hardware only (apart from external devices such as GPIB and PXI boards in an NI PXI rack). Rolf Kalbermatter

QUOTE (Neville D @ May 23 2008, 11:18 AM) That is the VISA passport for HPIB boards if I'm not mistaken. Rolf Kalbermatter

QUOTE (crelf @ May 22 2008, 07:38 AM) Well there might be all kinds of ramifications. For instance NI acquired a source code license to FlexLM for certain OSes (most probably Windows only) and certain uses (most probably allowing to protect their software with it but not allowing them to create a licensing Toolkit for use by people outside of NI). Macrovision (seems they are now Acresso) has been a well known company in copy protection business and I'm sure they employ quite capable lawayers too, so if I was NI I wouldn't try to go beyond what the acquired license allows, which I believe has certainly its price even with a non royality free, non free to use for everything license . Rolf Kalbermatter

QUOTE (Michael_Aivaliotis @ May 21 2008, 10:54 PM) Hmm, why makes clicking on that image give me a download box for a file accessmacro.zip? The link showing in the status bar points definitely to a jpg image. Rolf Kalbermatter