Rolf Kalbermatter

The OpenG PortIO package allows to access port adresses as well as physical memory adresses. This release (v1.2) adds support for physical memory acccess and also removes the actual kernel driver file from the system directory on uninstallation. You can download+install this package using VI Package Manager. Just press the "Check the Network for Available Packages" button to refresh your package list.

QUOTE (jw666 @ Nov 13 2008, 11:10 AM) const char *name is a C string pointer. So configure the according parameter in the CLN as a String of type C Pointer. double is the C equivalent for a LabVIEW double precision floating point number. So this will need to be a Numeric parameter of type 8-Byte double. The * indicates it is passed by reference so set it to Pass: Pointer to Value. The other has no * so it is Pass: Value. What the actual string should contain is of course entirely to the device or the DLL or maybe even both. Rolf Kalbermatter

QUOTE (MJE @ Nov 8 2008, 10:24 AM) MJE's recommendations are all valid. The biggest trouble will be probably the lpEventAttribute structure. This should be either a NULL pointer or a valid security attribute structure. Since you are not likley going to create child processes of your LabVIEW process a NULL pointer will be fine so go with that and configure this parameter as an UINT32 (or if you use LabVIEW 8.5 or better use the new Pointer type, which will take care of adapting to 64 Bit pointers once LabVIEW for Windows 64 bit will become available) and assign it a value of 0. Also the two Boolean variables might be a problem too although I wouldn't expect them to cause the function to fail, just do unexpected things. In Windows 32 Bit every parameter is in fact passed as 32 Bit value on the stack but if you declare it as 8Bit it's entirely up to LabVIEW if it extends that parameter to 32 Bit before pushing it on the stack or if it just fills in the 8 Bits leaving the other 24 Bits at whatever random value they might be. This would mean that whatever you do pass in as Boolean value it is very unlikely that the function will ever see anything else but non-nul (or TRUE for that matter). Rolf Kalbermatter

QUOTE (professor_rumsdiegeige @ Oct 31 2008, 06:13 AM) No! LabVIEW for Linux simply does not contain any support for accessing .Net and hence Mono. It would also not be easy to do that since MS does not support compilation for Linux so even their .Net headers are simply useless for a Unix compilation of LabVIEW. Which would mean the LabVIEW developers would have to use Mono libraries and headers and since Mono is still heavily in development it would be very difficult to support that. LabVIEW as a precompiled binary can only contain compiled libraries and those libraries would contain code of the Mono development system used when compiling LabVIEW. That would mean it would only work with certain versions of Mono and would fail with older as well as newer improved version. All in all a lot of hassle for little gain so no I don't think it will happen very soon. Rolf Kalbermatter

QUOTE (DanielChile @ Oct 27 2008, 03:14 PM) Actually I haven't. Have been in communication about it at some time with them and you can request an evaluation version, so I think it should be fair. Rolf Kalbermatter

QUOTE (DanielChile @ Oct 27 2008, 09:11 AM) There are some Alliance Members that do actually sell their localization solutions. Some are more or less a VI library, others come with extensive support for text editor interfaces for importing and exporting the relevant strings into a text format that can be easily handled by a professional translater without any knowledge of programming, including LabVIEW itself. Toolkit type software: SEA Datentechnik GmbH, LabVIEW Localization Toolkit NI Resources http://zone.ni.com/devzone/cda/pub/p/id/99 http://zone.ni.com/devzone/cda/tut/p/id/3603 http://zone.ni.com/reference/en-XX/help/37...ng_labview_vis/ Rolf Kalbermatter

QUOTE (crelf @ Oct 24 2008, 09:22 AM) Quite what we do here too including traversal of containers like tabs and subitems such as ring control texts, but the translation files get soon difficult to maintain and therefore we also try to avoid it if possible. Also you often end up not only translating captions but also data elements itself and that is even more complicated to get right. Rolf Kalbermatter

QUOTE (dannyt @ Oct 23 2008, 03:07 AM) Before LabVIEW 8.0/8.2 I sometimes made a specific resize state in my state machine that actually explicitedly moved and resized all relevant controls according to the FP size. Quite cumbersome and not very easy to maintain but a big wow effect for anyone seeing how the controls always resized exactly in proportions to the screen size. With LabVIEW splitterbars this is actually quite a bit easier and more functional. Michael Aivaliotis gave a very interesting presentation on NI week how to use the splitterbar to actually get a seemless scaling user interface without the need to explicitedly set individual control sizes. Rolf Kalbermatter

QUOTE (Paulus @ Oct 22 2008, 06:56 PM) LabVIEW uses internal to the diagram whatever endianess the CPU prefers. only when flattening data to a stream or unflattening it from it (Flatten, Unflatten, Typecast, Binary File Read and Write) does it apply endianess conversion (in LabVIEW >= 8.2 by default, before that always) to make sure data is in Big Endian format on the byte stream side. So the data passed to your DLL is really in whatever format the CPU desires on which LabVIEW is running, which in your case is the same Little Endian format as what your DLL expects. My only explanation is that you interprete the data structure wrongly. While elm in itself is indeed a pointer it is not a pointer inside the main structure very much but the entire array is inlined into the main structure. This means you see the start of the data at byte offset 4 relative to the start of the structure. On some obsolete platforms (SPARC) the offset would be actually 8 since LabVIEW has to align floating point values to their natural byte boundary for the Sparc CPU to be able to access it without a huge perfrmance penalty but on Windows LabVIEW uses byte packing for all structures since the x86 architecture has little or no penalty for such access. Did you include extcode.h in your program? If not you have to add an explicit #pragma pack(1) before defining your structure and best reset it back to the previous by using a #pragma pack() after. Microsoft VC uses 8 byte alignment by default. Rolf Kalbermatter

QUOTE (LV_FPGA_SE @ Oct 23 2008, 08:38 PM) If you read this thread you will see that his complain against the world is that nobody wants to give him the job he would want. So what he really wanted to say here was probably more like: "Those who are talking about prostitututes don't get a job, just like me." However he fails to see that often it is not just what you talk about but also how. And nobody wants to get accused to be below "animal level" whatever that means . But with his bold and out of the blue statements it is both completely unarguable in a any sense as well as pretty unlikely to not feel accused :ninja: . Any critic is not only not answered to but simply overrun with all the same bold and out of blue statements again. Definitly not someone I would like as a collegue. Rolf Kalbermatter

Somethng that has bugged me a few times now and that I haven't found in here. So I'm adding it for documentation purposes. When single stepping with highlighting through a diagram in LabVIEW 8.2.1 I mostly see #0 as number of elements getting out of various array producing nodes in the text produced by highlighting mode where aan according probe shows clearly that there are elements in the array. Does doesn't seem to occur in 8.5(.1) anymore. Rolf Kalbermatter

QUOTE (Yair @ Jul 15 2008, 10:58 AM) It's definitly wrong! I would be not surprised at all if the first order wouldn't work as it is not a common feature for a server to change it's port number after it has started. But that setting the port and then starting does not work is really doing things backwards RolfKalbermatter

QUOTE (raymyster @ Oct 19 2008, 01:51 AM) It may or may not install in 8.5 I'm not sure. In general Toolkits should support a few earlier versions of LabVIEW but the category Toolkit is a bit stretching for the DSC module. But you are going to install a whole DSC system too that you may not want to use. The graphics itself will work in LabVIEW 7.1 too, the Image navigator and the DSC controls which are part of the LabVIEW DSC mocule will not howver. LabVIEW 7.1 was without proper license activation so there was never a way to download evaluation versions for Toolkits and such and the evaluation version for LabVIEW itself was a specifically compiled version of LabVIEW where certain features had simply been removed. Rolf Kalbermatter

QUOTE (Val Brown @ Oct 19 2008, 05:32 AM) Because it is to difficult for some LabVIEW newbies to actually select the right ActiveX component in a list of many hundreds if not thousends of ActiveX components as available on a typical Windows installation. There are many other things in LabVIEW that are not really necessary (eg. Express VIs) as you can achieve them with other more generic functionality often just as easy and with more detailed control but are there for the casual LabVIEW programmer that prefers to have a point and click option instead of having to do some programming. Also the way you describe the problem seems to indicate that LabVIEW is implementing some sort of callback mechanisme that is used by WMP that other containers usually don't implement. So it would seem to me to be overcompliant with MS rather than doing something wrong. Rolf Kalbermatter

QUOTE (Val Brown @ Oct 18 2008, 09:07 PM) I'm pretty sure that this behaviour is not there for nothing. Most likely it works around some other flaw in ActiveX containers, either a generic ActiveX problem or a more specific issue to certain types of ActiveX controls and the way NI had to implement the container to fit into the way LabVIEW has to hook into Windows events to do its other stuff. ActiveX containers hadn't been really thought out to well when they were introduced by Microsoft and they had later to find all kinds of bandaids to make it at least work reasonably. The fact that it is not an issue in other media player ActiveX controls also points to the fact that it is not a generic LabVIEW ActiveX container issue but definitly something in interaction with a certain aspect of the WMP component. Rolf Kalbermatter

QUOTE (crelf @ Sep 30 2008, 09:56 AM) In fact it is 260 minus 1 characters since the MAX_PATH constant in the Windows API is 260 and you need one character for the terminating NUL character. However some Unicode Windows API functions can work with longer filenames, if they are formatted as UNC. Rolf Kalbermatter

QUOTE (normandinf @ Oct 14 2008, 06:10 PM) Actually using a For Loop with autoindexing would be quite a bit more efficient than using Index Array and Build Array. If you would need different operations on different indices you could still implement the operations in a case structure wired to the loop index counter. Rolf Kalbermatter

QUOTE (rajprj81 @ Oct 12 2008, 10:39 PM) There are many threads about accessing serial instruments in general and AT command modems specificially here on this forum. Basically if it works in Hyperterminal but does not seem to work in LabVIEW you have likely forgotten to append the carriage return and/or line feed to the command. Hyperterminal does this when you hit the Enter key. LabVIEW simply sends whatever you tell it to send in the string. You also can enable VISA to append a single character automatically through VISA properties but I do prefer to disable that explicitedly and instead append those characters explicitedly to the command strings. Rolf Kalbermatter

QUOTE (jgcode @ Oct 7 2008, 05:52 PM) I think the virtualization for INI files inside the Program Folder is not realized by virtualizing file IO access to that location but is part of the Windows OS API (GetPrivateProfileString() and friends) used to read INI file settings. Since the LabVIEW INI file VIs are however build entirely in LabVIEW and access INI files through basic Win32 API File functions, this virtualization is not available there. Rolf Kalbermatter

QUOTE (Val Brown @ Oct 9 2008, 12:35 AM) I'm not sure there is much that NI could do here. It seems really more like a bug in WMP to me. Rolf Kalbermatter

QUOTE (Aristos Queue @ Oct 9 2008, 10:24 AM) You are completely right here :-). Not that I would expect anything else from you! Rolf Kalbermatter

QUOTE (PJM_labview @ Oct 8 2008, 12:26 PM) No! LabVIEW uses its own completely self cooked widget library. Basically a highly object oriented thing but all implemented in standard C way back in LabVIEW 2 days. So a LabVIEW window is in fact an OS window but anything inside that window are simply self generated widgets using drawing primitives of the underlaying OS. In the case of Windows LabVIEW actually draws lines (vectors) using Windows GDI, for the Mac it uses (used?) Quickdraw, and for Unix it directly uses XWindows drawing primitives. So as far as the OS is concerned there are no UI objects on a LabVIEW front panel but simply lines, circles, rectangles and text. That said it should be possible to capture the EMF drawing of a LabVIEW frontpanel by getting Windows to render the redrawing of a window into an EMF context instead of into the window. How to do that is however probably quite tricky. I know that it worked perfectly in Windows 95 as I have often gotten screen shots into MS Word that scaled nicely. In newer Windows versions it was a bit more tricky but it is usually possible. The way I do that is by using the Crtl-PrntScrn keyboard shortcut which gets various capture formats of the currently active window into the clipboard. many applications choose to pick the BMP format from the clipboard when it is available but Word seems to prefer EMF resp. WMF if it is there. You do of course need to have an application that does know how to deal with these metaformats properly. PS: Mesa aka. OpenGL is only used for the 3D controls and there mainly for the alpha shading but for the rest those controls are simply native LabVIEW widgets as all other controls too. Rolf Kalbermatter

QUOTE (jpdrolet @ Oct 1 2008, 08:12 PM) lol! In C you wouldn't even think about asking for something like that I wonder if Perl has it. From all those strange programming languages I would expect it to be the first that would come up with such a universal superduper format specifier. Rolf Kalbermatter

QUOTE (shoneill @ Oct 6 2008, 06:08 AM) Nice ! That's what you can call International relationships. QUOTE (normandinf @ Oct 6 2008, 08:54 AM) If she left Romania, then she might be in the 2%... That may seriously messup alfa's calculations, if more do that QUOTE (Phillip Brooks @ Oct 6 2008, 10:05 AM) I think alfa suffers from one or more of the following: Martyr complex Superiority complex Malignant narcissism And I think you missed a few He's the typical forum post attention seeker. Putting out wild statements, and when people react he simply adds more wild statements to it. Rolf Kalbermatter

QUOTE (shoneill @ Oct 6 2008, 04:39 AM) Just a short hyjacking of this thread Looking at your national flags I wonder if you are Irish and living in Switzerland or if your Irish flag is to something else related Rolf Kalbermatter