Neil Pate

And then I have two problems...

Yup, and now we are way too deep in the rabbit hole. A standard boolean does pretty much exactly what I need it just does not have an icon on it. As soon a NI open sources LabVIEW we will be able to fix things like this 🙂

But mouse down fires off when the user clicks anywhere in the path, I am after just the browse button. I ended up replacing the button with my own one and it all works ok, just a bit of a bodge.

Does this work at runtime in an exe? I never thought to try this, thanks for the suggestion. The problem is I need to set the default value as soon as the browse button is pressed, not before. There is no event exposed that will trigger when the browse button is clicked.

Sure, but changing the port fixed things, which is surely just a number in a packet datagram somewhere?

I have seen something similar. I supported a system that had 10 cRIOs all transmitting UDP data to be logged at a reasonable rate, and packets would indeed just get "lost" (as noticed by the receiver PC). I never did any analysis to see if they were not being transmitted or not being received, I just solved the problem by using a different port per cIRO.

The best thing about a UDP joke is I don't care if you don't get it.

Thanks James. I may be able to fix this then by colouring those arrows to be the same as my background colour rather than transparent. Edit: even more strangely, colouring them a colour and then back to transparent causes the problem to go away Edit2: LabVIEW is now behaving but the exe displays the same problem. I am going to leave this for now and just use the system control. If I get a moment I will try and fix it but for now I am moving on.

Will check it out. I am on a new laptop so need to install the Flatline controls again. Edit: no everything seems to be behaving now. One strange thing, I see the latest Flatline slider has a round grab handle; has it always been like this? If so then I have no idea where I got my slider from as mine has a rectangular grab handle. Anyway, for now just going to use the system control (which is not ideal as I would like to be able to colour the grab handle to match some other colours on my GUI).

So weird. I have replaced it with a system control and everything is now behaving as expected.

Take a look at the attached control, all it is is a slider (which I think I modified from the flatline controls from drjdpowell) When I just open this in LabVIEW, not even anything running, my CPU usage jumps from about zero to nearly pegging one of the cores of my PC. Weird... Slider_Test.ctl

The bug I mentioned is not in the LabVIEW control, it manifests in the Windows file explorer dialogue that pops up.

Thanks, thats what I ended up doing. It works ok but a Windows bug causes the text to be pushed out of the control, so I had to then applying this fix: http://etchingpathways.blogspot.com/2012/07/labview-simulating-keyboard-events.html

Does anybody know if it is possible to configure the path control so that when a user clicks the browse button the file dialogue that pops up has a custom filename pre-populated? You can do this easily with the dialogue prim, but I cannot figure out how to do this with the path control. I thought perhaps there would be an event that is fired off on browse, but it does not appear so. I suppose I could hide the browse button and replace it with a regular button...

Without fail I have always experienced deep disappointment upon finally looking at the code hidden away by NI's. VIs tend to fall into one of two categories: wow that is such messy code no wonder they keep it locked way! DLL call... blergh

Yes I have definitely seen stuff like this, but going back many versions. Kind of like using the internet in 1996 on a 9600 modem 🤣

I think ShaunR is in to something here. On LV2015 Quite often LabVIEW will get itself into a mode where in order to box select something I have to go completely around it rather than just partially around iy. No idea what causes this to change, but it pops up on my dev PC every few weeks. No driver change has happened inbetween and then it usually just fixes itself. @Darrenhave you got any of the "speedup" keys in your LabVIEW.ini set?

As a consultant I have to work with whatever code my customer has developed. Some of it does indeed take several monitors to scroll across and I just have to deal with this. The IDE should not choke or do "stuff" constantly while I am editing. Also, as is pretty common during development my code spends a lot of time broken as I develop or refactor stuff, and I have to deal with missing VIs all the time as I integrate other team members code back into the main branch. As LogMAN pointed out, the behaviour of the selection rectangle is so much quicker in 2015 (at the expense of the "amazing must have could not live without" feature of shading the contents of the rectangle). I bet ShaunR is having a quiet chuckle about this whole thing as he gets to use 2012 or something like that. Sorry if I am coming across angry, but I am. LabVIEW is not exactly a new immature product that is given away for free. We really should not put up with this rubbish. If I have to wait for my IDE to draw a shaded rectangle, regardless of the quality of code underneat, something is deeply wrong.

Please don't give them any ideas...🤦‍♂️

LogMAN that looks a lot like what I see on my PC, thanks for confirming. As you say, how can this stuff even make it out the door? ITS A SELECTION BOX, HOW CAN THIS BE SLOW. WHAT IS LABVIEW DOING??? 🤮 NI STOP MESSING WITH LABVIEW. ARE YOU TRYING TO GET US TO LEAVE THE PLATFORM?

Definitely not a notebook. It is a two week old PC, the fastest thing I have ever used. 32 GB of DDR4 RAM, Xeon CPU, extremely fast SSD and a good GPU. LabVIEW struggles to draw the grey selection box around stuff; it is actually a bit embarrasing. If I open a new VI and draw the selection box around a single structure it is "ok" but still quite sluggish. Trying to edit anything sensible leaves me with a slide-show for any editing operations that cause stuff to be redrawn. I have now turned off all options like auto wiring etc and its a bit better, but it is 2019 now. Editing operations in an IDE should not feel slow.

Because a queue is not a class. (I guess you know that, you are more trying say why is it not possible to be able to do this in the language...)

So then can the queue contain objects of the base class? Without seeing much more than this tiny bit of the solution it is a bit tricky to visualise a way forward.

Don't think you can do that, I think a queue ref cannot be dynamic dispatch, even if it contains a class. I am not sure I really follow what you are trying to do, but could you flip the logic around a bit, and have the queue ref as like the second input terminal, and have a StartRun input as the dynamic dispatch input? So you Enqueu Serial Number class which you have shown would have the StartRun object as the primary DD input?

Still not getting you, sorry. You want to wire a queue of classes into a class terminal? Can you post your demo project? Just because the classes might have a hierachy surely that does not imply anything about a queue that may contain these? You cannot set dynamic dispatch on a queue ref, can you???? (it is not a class itself)