Rolf Kalbermatter

QUOTE (mesmith @ Nov 11 2008, 02:43 PM) Additionally there is the possibility that msvcrtd.dll or one of its versioned siblings msvcrXXd.dll relies on yet other DLLs that are in debug versions and get installed with MSVC only. Rolf Kalbermatter

QUOTE (caspar @ Nov 25 2008, 05:11 AM) Quite likely. This behaviour in 8.5 was not a bug that got introduced but instead a change to the behaviour to make the .Net Interface in LabVIEW behave the way Microsoft meant .Net to be used. In earlier versions LabVIEW tried to be smart and locate dependant .Net components itself but I'm sure that opened a whole can of worms that was remedied by simply relying on the .Net behaviour itself. Rolf Kalbermatter

QUOTE (mesmith @ Nov 24 2008, 07:14 PM) Mark is completely right in all he says. The debug versions of the MSVC runtime libraries only get installed when you install Visual C or maybe an application with MSVC runtime support compiled in debug mode, although I'm not sure the debug version of the runtime libraries really belong to the redistributable part of Visual C, so such an application if not from yourself may be not legal. It's most likely a somewhat misleading error message in the shared library loader. LabVIEW has had traditionally a certain number of well known error codes. When adding a new subsystem the developer always had two choices: Adding a new error code for every situation or trying to find an existing one that matches the situation fairly well. Adding new error codes used to be a major hassle since all the necessary information had to be entered into the resource files of LabVIEW too which is a completely different work flow chain than editing the C source code, so the choice was usually towards reusing an existing error code. When LabVIEW asks Windows to load a DLL on its behalf Windows will fail the loading if a dependency can't be satisfied. The returned error code is sort of generic and there is virtually no way to get the information about what dependency was missing unless one would walk the entire import tables of the DLL and its dependencies. Translating OS specific errors into Framework specific errors is always a tricky and lossy business. Nowadays the errors are not as tight into the LabVIEW Framework itself so the choice is more often made to add subsystem specific error code ranges but the Call Library Node shared library loader code dates back to LabVIEW 3 and at that time priorities and possibilities were quite different. Rolf Kalbermatter

QUOTE (Paulus @ Nov 24 2008, 01:12 PM) That obviously avoids the alignment problem. 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