dadreamer

I tried to be a little ironic, but failed, it seems. To clarify, I almost don't believe, LV interaction with OS native callbacks will get same enhancements that were made for .NET. The Call Library Function Node didn't get enough love since LV6 or 7.0 and a little more attention has been given to the Register Event Callback node, introduced in LV7.0. Of course, I could propose an idea at NI Idea Exchange section, but I'm pretty sure it won't receive enough kudos to even shift the priorities in the NI's internal development list.

It should also automagically install Visual Studio, write the callback wrapper, compile it into a DLL and connect it to the VI with a CLFN. Moreover it would be nice to have a .NET translator from textual code to G code, as the current way of calling .NET assemblies is too awkward. It may take 10 minutes to find a good combination of Assembly -> Constructor -> Method/Property, especially when dealing with the OS native API.

I would first increase the timeout input on the Create Network Stream node in ApplicationA.vi, so the value would be equal or higher than 160 ms, as I recall some problems related to the timeout being small: Timeout influence at Create Network Stream Endpoint Of course, it may be not your issue exactly, but worth trying anyway.

For that I have left this sentence with a reference to your message and the next ones after: But I would say that size_t type rather depends on a target bitness, than on a platform bitness. On 32-bit OS we can compile 32-bit applications and cross-compile 64-bit ones, if supported by the compiler. On 64-bit OS we can freely compile both. So sizeof(size_t) is either 4 bytes for 32-bit target or 8 bytes for 64-bit target. I've just checked that in MS Visual Studio.

First, C unions are special data type that allows for multiple data types to be stored in the same location. Therefore you don't need to bundle each and every field defined in your header for that union. The union length is set by the longest field. So you should pass 4 bytes in both of your cases. It's up to the code on how to interpret that union onwards: either as uint32_t "value" or as four uint8_t fields struct. Second, you have two pointers in your main struct (pImagePtr and pUserPtr). You should pass them as 32-bit fields in 32-bit LabVIEW or 64-bit fields in 64-bit LabVIEW. To satisfy both cases, use Conditional Disable Structure with two cases for 32- and 64-bits accordingly. Now you're passing U8 fields, that will likely lead to writing to the neighboring fields inside the shared library. The same applies to size_t parameters (read here for details). Maybe it would even be easier to make two different structs for 32- and 64-bits in Conditional Disable Structure instead of defining each parameter separately.

No, don't pass LabVIEW arrays straight to the cluster! They are different entity than those in C/C++. In order to match your struct definition, you have to turn each array into a separate cluster. Use Array To Cluster primitive for that. RMB click -> Cluster size on it allows you to specify the output cluster size. Then bundle all the clusters into one (plus three int parameters), then pass that resulting cluster to your CLFN. I assume, you know your .so's calling convention. Oh, I forgot to add, that Array To Cluster node doesn't accept more than 256 elements. So, if SV_STRING_SIZE is 512, you need to make a pairs of 256+256 elements (e.g., two "id" clusters, two "vendor" clusters etc.). There's another way with DSNewPtr+MoveBlock, but it's a bit more advanced.

So instead of the "IMG tab" wire, shown on your diagram, you now have a memory pointer to the data (of the same representation and layout)? If so, just MoveBlock it to a common LabVIEW array and proceed as usual. Also I slightly don't get the reason why you're doing two Marshal.Copy operations... On the diagram above that empty bitmap's data is copied into the LabVIEW array, then it is replaced with the "IMG tab" data (Replace Array Subset on zero row) and then the array is copied into the empty bitmap. Isn't it enough to copy the "IMG tab" data to the empty bitmap and do the rest of the code (UnlockBits etc.)? I can't run the snippet, as LAVA seem to strip the metadata out of the snippets.

I'm afraid, no way around that. I mean, without A LOT of low-level hackery. IMAQ images have borders 3 pixels wide by default, whereas LabVIEW arrays don't have those. And not every VI from the Array palette works in-place, not producing a copy. Of course, you may read/write pixels data by its pointer using MoveBlock. Like this: But I wouldn't expect more than that. You can always move the image processing into your DLL/SO and write everything in pure C/C++, C# et cetera.

If you are using VDM, you should already have the basic example on how to manipulate the IMAQ image in a shared library: IMAQ GetImagePixelPtr Example Don't know, if you will gain anything in terms of performance, but worth a try at least.

So, this is not what you want?..

Maybe this will help: Programmatically Scroll Front Panel Using LabVIEW

I think Andrey won't mind if I repost this here.

You can download PID and Fuzzy Logic Toolkit 2012, then unpack it somewhere (e.g., on your Desktop). Run this command in the admin command line: msiexec.exe /a "C:\Users\User\Desktop\2012PIDFuzzy\Products\LabVIEW_PID_Toolkit_2012\NIPID00\NIPIDToolkit.msi" /qb TARGETDIR="C:\Users\User\Desktop\2012PIDFuzzy\Products\LabVIEW_PID_Toolkit_2012\NIPID00\NIPIDToolkit" (Replace "User" with your username). Now go to \2012PIDFuzzy\Products\LabVIEW_PID_Toolkit_2012\NIPID00\NIPIDToolkit\ProgramFilesFolder\National Instruments\LabVIEW 2012\vi.lib\addons\control\pid\pid.llb and there you should have PID.vi along with many other VIs from that toolkit. Also note that some VIs use 32-bit lvpidtkt.dll, so it won't go in 64-bit LabVIEW.

They introduced a token for smooth lines: SmoothLineDrawing=False

The Type Spec Structure is accessible in LabVIEW 2017, if SuperSecretPrivateSpecialStuff=True is written to labview.ini and the user RMB clicks on the Diagram Disable Structure and chooses "Replace With Type Specialization Structure" menu entry.

Darn, I'm slow Started to upload my disks to GDrive and on finish saw your message. Anyway, good to know it's resolved.

Yes, looks much like you meant the 2D Picture pixmaps opcodes. Their names are similar to those from the QuickDraw PICT Opcodes document (e.g., frameArc, paintArc), but the values are different. On classic Mac OS I've seen the following. If a vector PICT image (of kLVPictImage type) is placed onto the panel and resized, it is redrawn as if it was a LV native kPiccImage. But when the VI is moved onto another platform, such as Windows, the image becomes a common bitmap, losing all its vector abilities. Seems, the presence of a platform-dependent API (such as QuickDraw) really matters. I'd add dynamic (un)registration of the drawing procedures for the cosmetics. It would allow to add custom decorations relatively easy, even though the Drawing Manager is undocumented to use in the DLLs. Currently no way to add the user decor, not having LV sources. But honestly all this legacy tech should be rewritten or even removed/replaced by something much better. EMF/WMF support is not that good and SVG is still not considered. 😿 By the way. This thread seems incomplete after @flarn2006posted in his profile some info to obtain all the decorations from lvobject.rsc. Here's the VI to do that: All Cosmetics.viChoose the .mnu path on the FP, run this VI, then import the subpalette in the standard way (Tools -> Advanced -> Edit Palette Set). Most of "hidden" elements are not that interesting as they're of no use as stand-alone decorations. Some could be useful tho, like those DSC module graphics (valves, pipes etc.), except for the Multi-Segment Pipe, maybe, because it's not functional as a decor. Or how about some cool gradient decors?

Have seen this statement of yours many times, but still don't see how you came to this conclusion. I investigated those built-in PICCs a bit. The "Cosm" resource forks in lvobject.rsc (labview.rsc in the old versions) don't contain any graphic operators. For example, this is how the Flat Box resource looks: 0000 0003 //cosmetic flags 0000 0000 00F0 0000 FFF0 FFF0 //rect 0010 0010 0000 0000 0200 0000 //symbolic color 0000 0000 0000 000B //image index to get later (e.g., 3D5) Now, this 0xB is just an index to the LabVIEW's internal structure, that can easily be observed in Heap Peek. Not very informative though. Here's the handler procedure address and some data, passed to it. Obviously not enough to do the drawing. This kPiccImage has 0x3D5 number assigned as well, which just indexes into the LabVIEW's internal table, looking like this: I marked the Flat Box line. Only two fields are here: the handler proc offset and the data, being passed into it. The data is in fact nothing more than the graphic attributes for the handler to draw, like the border width and the line style. Let's check this. I set the border width to 5 (instead of 1) and the line style to 0x11 (instead of 0x44). Easy to see: - Those PICCs are used in many places of the LV GUI. - Almost all the drawing work is done by the handler proc. - The procs and the attributes for the decorations/cosmetics are hard-coded inside LabVIEW. The proc itself uses the Drawing Manager functions to do the work. So, if it's the Flat Circle proc (to simplify), it behaves this way: DEmptyRect -> DSelectNormPen -> DPaintOval -> DSelectNormPen -> DFrameOval. It could easily be reproduced on the diagram: Draw Oval.vi The left circle is drawn from the diagram, the right one is a built-in decoration. Of course, it needs more work, when applied to a real project, as redrawing is necessary, when the window is resized, minimized, overlapped etc. The handler proc takes this job for the native cosmetics. So, I did not find anything that would resemble the Mac OS PICT format (version 2 or 1, at least). It is more like a "Picture in C" instead, as someone noticed earlier.

I have LabVIEW 8.0 Professional distro on three disks, that I believe was downloaded from torrents a while ago. The overall size is 1,68 GB. I'm a bit unsure whether it's ok to post it here. If the admin/mod's let me, I'll post it (without a "cure", ofc). As an alternative you may stalk for it in Google or other search engines. With pot luck you'll find it.

It's still on some trackers out there. Downloaded fine. This is the image without any hack tools inside. Or search the web for "NI.LabVIEW.v8.0.Real.Time.Module.ISO".

Yeah, I was thinking of double numbers whereas dealing with 4-byte integers, hence the confusion. In that thread I was introducing a filler field of 4 bytes in 64-bit LabVIEW using Conditional Disable structure. That's unnecessary here.

Seems like a feature really 🙂 I prefer not to use PN's without a serious need, as they run in UI thread, so have not tested that. It looks much like in this case the value is copied out of the DDO instead of the intermediate buffer. One way or another... it's working.

Its value remains constant (until you press the color of your liking), but its cosmetic color does update, that's why the Get Image method works, for instance, so it's possible to "catch" the moment, when the color changes, if the appropriate logic is implemented in the VI. Basic example. ColorBox Tracking.vi

No, not on the widget, you use Refnum to Pointer on the ColorBox control reference. After that you attach a debugger and study the memory dump to find out the cosmetics pointers in the data space (if you decide to go this route). You can get its HWND, but it's of no real use here.