Jump to content

Rolf Kalbermatter

Members
  • Content Count

    3,037
  • Joined

  • Last visited

  • Days Won

    151

Everything posted by Rolf Kalbermatter

  1. That's not as easy even if you leave away other platforms than Windows. In old days Windows did not have support preinstalled for all possible codepages and I'm not sure it does even nowadays. Without the necessary translation tables it doesn't help if you know what codepage text is stored in so translation into something else is not guaranteed to work. Also the codepage support as implemented in Windows does not allow you to display text in a different codepage than what is currently active and even if you could switch the current codepage on the fly all text previously printed on screen in a
  2. No Classic LabVIEW doesn't and it never will. It assumes a string to be in whatever encoding the current user session has. That's for most LabVIEW installations out there codepage 1252 (over 90% of LabVIEW installations run on Windows and most of them on Western Windows installations). When LabVIEW classic was developed (around end of the 80ies of the last century codepages was the best thing out there that could be used for different installations and Unicode didn't even exist. The first Unicode proposal is from 1988 and proposed a 16 bit Unicode alphabet. Microsoft was in fact an early
  3. The word hidden in there makes it look very exciting but the reality is that it is simply the toolbar buttons that are made invisible in the VI Properties. Apparently there is an enum that describes all possible permutations with individual enum labels and that enum gets also saved to disk but for performance reasons they decided to rather have a bitmask field to use at runtime. So this "routine" converts from the enum to the bitfield. There should most likely be another routine that does the reverse, most likely by running through the gButtonsHidden global array and comparing sr_field14 with
  4. An USB device implementing the TMC class! That looks very much like the underlaying USB session itself somehow got borked. Once VISA calls into the Windows USB driver it can only hope that this driver will return within a reasonable time. If the driver detects some problem with the hardware resource it just can hang there and VISA only can wait until the Windows driver decides it wants to return. Unfortunately the fact that it is a Thorlabs device (from the VID and PID in the USB session name it must be a PM320E Optical Power and Energy Meter) doesn't increase my confidence in the actual hardw
  5. (((*sr)->field_4 & 0xFF0000) >> 8 | ((unsigned int)(*sr)->field_4 >> 24) | (((*sr)->field_4 & 0xFF00) << 8 | ((*sr)->field_4 << 24); This is simply the BigEndian to LittleEndian swapping. All numeric values in the VI data structures are stored as Big Endian, since they need to be independent of the CPU architecture. On loading into memory on LittleEndian platforms (currently all but the VxWorks platform for PowerPC Real-time platforms, but in the past MacOS Classic (68k and PPC), Mac OS X for PPC, Sun Sparc and I believe HP PA R
  6. Old fashioned it may be but you seem to have a surprising high trust in Microsoft, Google, Amazon and CO to not only be able to secure their infrastructure beyond any doubt but also to never turn evil from inside and scan your files no matter what. Ohh wait Google does that already, their user rights document you have to agree to to use their cloud services specifically states that they are allowed to scan your documents for service improvement purposes. In terms of Google that also means to improve their ad business revenues, it's after all still their core business with which they grew to th
  7. You completely borked it! An array of clusters is not an array of pointers to a C struct! It's simply an array of clusters all inlined in one single memory block! Look at resize_array_handle_if_required() and what you try to do in there! The first NumericArrayResize() should not allocate n * uPtr anymore but rather use a type of uB and allocate n * sizeof(DevInfo). Of course you still need to allocate any string handles inside the struct but that would be done in: static MgErr add_dev_info_to_labview_dev_info(DevInfo* pDevInfo, const IIR_USB_RELAY_DEVICE_INFO_T* info) { MgErr err = m
  8. A the so called system color indices. Forgot about them. They are determined on startup based on the current OS scheme or possibly when Windows sends a system message that the OS scheme has been changed.
  9. Well a color in LabVIEW is simply an int32 with the lower 24 bits being an RGB color when the MSB is 0. There are a few special constants when the MSB is exactly 1, with the 0x1000000 value indicating transparent, and 0x1000001 is a special type for most recent color and 0x1000002 indicates an invalid color. I don't think there are any other values above 0x1000002 that have any meaning in LabVIEW. The color box is a control with a special display logic that shows the transparent color with the T on top. It is meant as color chooser more than a visual object and if it just would disp
  10. LabVIEW 2.5 was distributed on 3.5" floppy disks. About 4 or 5 or so of these in 1.44MB high density formatted. I ditched them several years ago as it is pretty hard to find a drive nowadays to read them. Later releases were substantially more floppy disk. I don't think CD-ROM was an option before LabVIEW 6.0.
  11. Thousends of releases? I kind of doubt it. Leaving away LabVIEW prior to the multiplatform version (2.2.x and earlier which only were Macintosh) there have been 2.5, 3.0, 3.1, 4.0, 5.0, 5.1, 6.0, 7.0, 7.1, 8.0, 8.2, 8.5, 8.6, 2009, 2010, 2011, 20012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 releases so far. Of each of them there was usually 1 and rarely two maintenance releases, and of each maintenance release between 1 to 8 bug fix releases. This does probably only amount to about 100 releases in total and maybe another 50 for beta releases of these versions (a beta has usually 2 to 4 interme
  12. Part of these is the Macintosh legacy. You could make a case that Microsoft is at fault as they had to invent differences to the Mac, either for the sake of being different or maybe also to not give to much fodder for a court case about plagiarizsme.
  13. There were a few errors in how you created the linked list. I did this and did a quick test and it seemed to work. The chunk in the debugger is expected. The debugger does not know anything about LabVIEW Long Pascal handles and that they contain an int32 cnt parameter in front of the string and no NULL termination character. So it sees a char array element and tries to interpret it until it sees a NULL value, which is of course more or less beyond the actual valid information. #include "extcode.h" #include "stdlib.h" #include "string.h" typedef struct IIR_USB_RELAY_DEVICE_INFO { cha
  14. uQ is the LabVIEW typcode for an unsigned 8 byte integer (uInt64). uL is the typecode for a uInt32. These are the sizes of a pointer in the respective environment and a LabVIEW handle is a pointer! You are right of course. That was a typo! But the real typo is in the declaration: LStrHandle *pH = NULL; The rest of the code is meant to have this variable be a reference to the handle not the handle itself.
  15. A string array is simply an array handle of string handles! Sounds clear doesn't it? 😄 In reality we didn't just arbitrarily create this data structure but LKSH simply defined it knowing how a LabVIEW array of string handles is defined. You can actually get this definition from LabVIEW by creating the Call Library Node with the Parameter configured to Adapt to Type, Pass Array Handle Pointer, then right click on the Call Library Node and select "Create .c file". LabVIEW then creates a C file with all datatype definitions and an empty function body.
  16. That entirely depends on the implementation. If the API just returns a pointer to a globally maintained list then there is no way to make this safe unless: 1) It only ever updates this list when calling this function just before returning the first element pointer. This means that updating this list because of OS events for unplugging devices is not a safe option. 2) It provides some locking such that getFirstDeviceInfo() acquires a lock and you have to unlock the list after you are done for instance by calling a function unlockDeviceInfo() or similar. Another option is that the
  17. There is a serious problem with this if you ever intend to compile this code for 64 bit. Then alignment comes into play (LabVIEW 32 bit uses packed data structures but LabVIEW 64 bit uses default alignment so the Array of handles requires sizeof(int32) + 4 + n * sizeof(LStrHandle) bytes. More universally it is really: #define RndToMultiple(nDims, elmSize) ((((nDims * sizeof(int32)) + elmSize - 1) / elmSize) * elmSize) #if IsOpSystem64Bit || OpSystem == Linux /* probably also || OpSystem == MacOSX */ #define ArrayHandleSize(nDims, nElm, elmSize) RndToMultiple(nDims, elmSiz
  18. In the case of the libraries that I contributed to OpenG, I tried to add all the names to the copyright notice who provided more than a trivial bug fix. I also happened to add my name to a few VIs in other OpenG packages when I felt it was more than a trivial bug fix.
  19. Well there could be two that apply! "Killing me softly" and "Ready or Not, here I come you can't hide" 😀
  20. The upgraded LLB almost certainly never ever will happen. The lvclassp or whatever it would be called probably neither because you can do that basically today by wrapping one or more lvclasses into a lvlib and then turning that into a lvlibp. While these single file containers are all an interesting feature they have many potential trouble as can be seen with lvlibp. Some are unfortunate and could be fixed with enough effort, others are fundamental problems that are hard to almost impossible to be really done right. Even Microsoft has been basically unable to plugin an archive system like
  21. In general you are working here with non released, non documented features in LabVIEW. You should read the Rusty Nails in Attics thread sometimes. Basically LabVIEW has various areas that are like an attic. There exist experimental parts, non finished features and other things in LabVIEW that were never meant for public consumptions, either because they are not finished and tested, an aborted experiment or a quick and dirty hack for a tool required for NI internal use. There are ways to access some of them, and the means to it have been published many times. NI does not forbid anyone to use th
  22. I would say the error message is very clear! The desired call is not supported in the current LabVIEW version. Why do you think this should work?
  23. Hmmm, maybe LabVIEW learned as some point to do that cast if you pass a file refnum to the pointer sized integer input on a Call Library Node. Never tried that!
  24. Yep I know! Linux is a fileID, except there are at least two different types of identifiers, one is a socket like one and one is a posix file IO one. Mac is nasty. For 32 bit it seemed to be a Carbon API FS number, later changed to the posix file IO number for 64 bit. Not sure they changed anything for 32 bit too. The differences and uncertainities make it not a safe bet to just ASSume things and HOPE it will always remain like this, sorry. But nooooo, a file refnum is NOT a Windows file handle. Pease repeat after me: IT IS NOT!. You need the file manager function FRefNumToFD() to retriev
  25. It's called bindings to non native libraries and functionality. It's a standard problem in every programming environment. The perceived difficulty has always a direct relation with the distance of the programming paradigme of the calling environment to the callee. In C it is almost non existent, since you have to bother about memory management, thread management, etc, etc. no matter what you try to call. In higher level languages with a managed environmen like LabVIEW or .Net, it seems a lot more complicated. It isn't really but the difference between what you normally have to do in the callin
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.