Neil Pate

I am just getting started with LV2017 on a new project, and have found some horrrible IDE "improvements" that are messing around with my work-flow. The first one is auto-wiring when you drag code into a stucture (as discussed here). My latest gripe is strange behaviour when dragging a VI from one BD window to another. I do this operation quite a bit to copy code. In LV2017 now when I drag a VI in from another VI as soon as it enters the new VI (but before I have released the mouse) it is as if the block diagram of the target VI only refreshes like once a second and so I see my VI jerk around. It does this the primitives as well as other VIs. I cannot comment about LV2016, but at least in LV2015 and every other version I can remember, dragging a VI from one block diagram to another was butter smooth. Anybody else seen this or is it just me?

Found this on LinkedIn. https://0patch.blogspot.co.za/2017/09/0patching-rsrc-arbitrary-null-write.html Not going to pretend I follow most of what they are talking about, I am just surprised that something as niche as LabVIEW is even being tested for vulnerabilities.

I have fought this for close to a decade trying to get a slick splash screen that does not exhibit some stupid behavour like spawning before the application is even ready to run (so showing toolbars etc), not being centered etc. I currently have the same code that works differently on difference PCs due to their speed. Eventually I just stopped getting annoyed by ignoring everything as virtually nobody even comments on it.

I have just wrapped the VI mentioned by the link hooovah posted in some code that iterates over all the classes in my project. I really have no use for the mutation history and wish I could permanently turn it off. Also I think it is buggy especially when classes contain classes that have changed or been renamed. Seen some terrible IDE bugs related to this.

Yup we were trying to be positive. I have not experienced too many crashes involving classes lately although I do purge the mutation history every few weeks (No problems with a medium size project including approx 85 classes).

I have had good success using the NI Database toolkit.

I usually have one user event per "actor" which is used to broadcast when its state changes. Recently I have been playing around with not using the event data terminal and instead having a global data repository implemented using a DRV to a variant (with the data stored as named attributes), the actors user event data is a timestamp that I set when I generate the event. If I had a cent for every time I have created and deleted the register event terminal which never propagates properly...

Even to this day when I open a random VI from my project, click run-continuously and quickly iterate through some input scenarios to make sure the VI is still working as expected makes me smile. No additional code needs to be written to quickly test a single VI, I just love this

James I agree, I did report the post a few days ago.

Managed to get this working in the end. http://labelary.com/viewer.html

That file format looks an awful lot like the one used internally by LabVIEW if you use DAQmx channels in the project. A long time ago I asked if there were any available tools to parse these files (as they are read at runtime in a .exe) but did not have any response.

Nice tip, thanks! I tried that and it seemed to generate some sensible ZPL. Interestingly it is using ^GFA rather than the ^GFB which I was trying to use. I do not have access to the printer anymore but should be able to test soon.

Thanks Phillip, I did actually try there first, there are some nice threads on zebra specific stuff, but the forum would not allow me to post for some reason! Will try again.

Firstly, although I was able to get the custom VISA driver to work (USB Zebra printer) I have reverted back to this technique for getting the printer to work. Have had good success with it. Now onto my problem. I want to print a logo on a label and am struggling to get the ^GF command to work properly (with binary data). I can successfully print a stripe pattern but am not having any success printing the actual logo. In the attached code (very rough prototype code just to get me up and running) I can print a stripy pattern (0xF0, so 11110000 alternating gives me columns of printing in the desired dimension) if I change the selector input to a T (to print my bit-packed logo) nothing prints and the printer seems to get stuck. I do not understand what the problem is as I just assumed, even if my logic for packing the logo into bits is incorrect, I should still get something printed. If I force the top bit high in my bit packing routing I get something printed but obviously not what I expect. Any ideas what could be wrong? I have tried lots of variants of this code without any success. I am stumped why it does not print. My only conclusion is that Windows is mangling the string commands because technically I am sending null characters and backspace etc in my binary data, but I really just assumed the printer would interpret this stuff correctly. logo (64x64).bmp Print Test 5.vi

Rolf, I did see the Rect input, but at the time I did not really consider it useful as I did not know that the problem was related to the image size. Now that you have pointed this out I think that would definitely have helped. I am still getting strange out of memory errors which I have no been able to track down but I strongly suspect are also due to the Picture control functions. Time to use the Rect input I think!

I do not do too much vector darwing, but under some (error) circumstances I have realised the coordinates of my drawing instructions could actually get quite big (as in 32k *32k), I just assumed the picture would be constrained in size to the size of my pixmap data which is not huge, but probably given what you say this is actually causing the out of memory error. Knocked up a test VI to simulate this error condition and I think this is exactly what is happening for me. A line being drawn from (0,0) to (32000, 32000) and then an attempt to get the pixmap will definitely cause problems!

Nice link. I had seen some of Norm's earlier stuff on the internal implementation. For now I have worked around my problem by not using that VI, when I get a moment I will investigate my problem further as I would like to understand why it is happening.

It is interesting to peek inside the picture control VIs and realise they really just implemented as strings. Also it is useful to know most operations are additive (i.e. makes the string longer, even if you perform the same action like draw the same line twice). The offending VI that was causing me problems is password protected, but it just wraps the DLL call PictToPix so this did not really help me.

Tim, I am updating the picture control once per second with (potentially) an entirely new picture of 540x960 pixels, although I could easily cause the condition using the same image that has already been successfully displayed.

Hi gang, I have just gotten to the bottom of a rather nasty bug that can cause an out of memory error in LabVIEW. It seems that under certain conditions that I cannot easily recreate in simple code the Picture To Pixmap primitive will attempt to allocate infinite memory. This manifests as a virtually instantaneous increase in the LabVIEW (or built exe) process up to the 2 GB limit and then the "out of memory" dialogue. The only input to this function I am using is the picture which I have formed using the standard primitives (so no trickery going on with me attempting to create the picture using string manipulation that I know is possible but have not attempted). Anybody else seen this?

Thanks Thoric, I did quite a bit of googling but that forum link did not come up. Guess I will have to live with a non-LabVIEW solution (for now).

Actually this WinExplorer application is not part of the SysInternals Suite (which yes does rock without doubt). I was just poking around now in the SysInternals Suite to see if they have something similar but cannot find one.

Strangely it seems there are two "somethings" for my LabVIEW executable (a LVDChild and a LVFrame class). Unfortunately this WinExplorer software does not seem to have support for the WS_EX_NOACTIVATE style. I suspect LabVIEW is doing a lot of its own window management behind the scenes. Bah humbug.

Yeah, I suspected the same thing so I tried building an exe. It behaved the same as in the IDE. I am going to try this.

Hi All, I am trying to make an on-screen keyboard (OSK). I have previously created a nice one that works perfectly if you can feed in the reference of the control that has focus. However I cannot seem to reliably get a unique control reference for several circumstances (e.g. an element of cluster that is inside an array). So I decided to try and make my own, in the spirit of the code of this open source project: https://sourceforge.net/projects/numpad-emulator/files/latest/download?source=typ_redirect The crux of my current problem is that whenever I click on one of my buttons of the OSK the focus is brought to the new window, and therefore I cannot direct the text into the control that previously had focus. I believe the way to solve this is to use the WinAPI to set the Extended Window Style of my OSK to be WS_EX_NOACTIVATE. According to MSDN "this style allows a top-level window created with this style to not become the foreground window when the user clicks it. The system does not bring this window to the foreground when the user minimizes or closes the foreground window". This is the technique used by the Numpad application I have linked to earlier and works perfectly. Attached is my attempt. The hex style 0x8000108 is what Numpad uses for the window style. I can successfully control this application from my LabVIEW test to turn on or off the NOACTIVATE by setting or resetting the greater "8" bit in the config. This just does not work for my LabVIEW window though. Any ideas? Num Keypad.vi