Olivier Jourdan

Add SHIFT key to up/down

I would be very interested to know what are thinking LabVIEW R&D engineers about this feature request. I've came across this "issue" developing XControl and I think it's a "normal" behavior. Having the XControl waked up by dynamic event should imply that you have two ore more event structure waiting for event in the "same" vi. This can be "funny". I hope I'm wrong and I hope to see this feature added to next LabVIEW release.

Inheriting from pre-existing control would be great. Re-writing code is not really an enjoying work. One "shortcut" I've done to solve this issue is to expose the reference of the facade.vi objects through XControl properties. Even if it's not the best solution, it allows you to access quickly to all properties and methods writing usual code. This "workaround" has, at least, one lack, it not allows basic XControl user to modify properties righ-clicking on the object as he used to do with "classic" control. In any case, having a way to choose properties/methods to automatically exposed to end user would be a great feature to add in next LabVIEW release

We use Mantis to track bugs changes needed. However, this is most an high level of tracking, IMO this is not really useful to spot one particular VI as the first post is about.

You're right, but an underling is should be able to do "CTRL+F" To be fair, this solution is quite simple and have some lacks but it is also quite easy to use and to maintain.

I opted for "TODO" comments too and I use the integrated "Find" feature of LabVIEW to list remaining things to do.

CAR# 279707

Hello JG Reading again this thread, I notice that this workaround have a lack. You'll lose the recording mechanism integrated in the facade.vi. if you never write "Data". This can be really annoying if you want to distribute your XControl. It won't behave as the user expect to. We really need a bug fix from NI Regards

The one working right is the one done in 8.5.1 ?

Bug reported to NI.

Hello, Have you read this post : ? However, I've never noticed refresh delay on XControl. Can you replace your XControl by an "simple" indicator and look at the behavior ? Is it the same or is thi fix the issue ? Regards

Hi asbo The XControl should beep many times. The beep occurs when "the bug" occurs. On my PC, the quicker you move the slider the more often the beep occurs. 2 or 3 go-backs only to have the beep. I really don't know how events are managed in an XControl. The fact that the "bug" occurs when lots of value change are fired let me think there is probably a link wit this other bug found by JG --> http://lavag.org/top...dpost__p__79794 However, I've came across this issue in a different case: In a code implementing an XControl for long time without problem, I've added a value change event on the Xcontrol. The simple fact to add this event case cause the XControl refresh with "default values". Next event on it refresh it with the correct values. This is a bit different from the example I've posted but fix is the same --> do not refresh when i =0. Regards

Thank you for testing the code. I'll wait for other test/comment and then report the issue to NI Thanks, Olivier

Hi, Lately I came across a weird behavior on XControl. I think I've find out the issue but want to you to confirm the behavior. As far as I understand XControl execution theory, it's impossible to have facade VI executing only one iteration loop (just TimeOut case called). However I can obtain this on certain condition. This should not be a problem if data (display state and Data) was not reseted to default value. Ui refresh code called with these inconsistent data give some really weird behavior (NB: data are not lost, next call give the consistent data...) Here you can find the step to reproduce the issue : Create an XControl Add a slider on facade.vi FP Add beep.vi in a "0" case, outside the while loop, link selector to while loop "i" Add "Slide:Value change" event case Add "Slide:Mouse Enter" event case Drag the Xcontrol in a new VI FP Issue appears after step 5. You'll find an example of this behavior in attachment. I've reproduced the issue in LV2009-SP1 and LV2010. Can you confirm me that you have the same behavior on your side ? Work around is easy, but I think this deserves a bug fix from NI. Regards, Olivier XCTimeOutIssue-2009.zip

Hello, Implementing a non polling process based on queue is possible. One thing to take care with user event is that, as far as I know, you can't manage the "buffer event". This can cause UI slowing done. Regards

Definitely not a big issue, but this solution is not multi-platform (mouse input VIs are not available on Linux and Mac)

Hello all, Just a small message to tell you that we have shared a small package of custom probes here. This is not revolutionary, we just hope that it'll help you to find and fix bugs in your code. Regards, Olivier P-S : LabVIEW 8.6 or later and VIPM 2010 needed.

Hello, issue with properties seems to be more frightening... Seemingly, create a method doesn't work as it's works in previous LabVIEW version. New method created is view as a simple VI by Xctl If you try to open XCtl properties you obtain the following messages Then, property window exit To fix this you need to close the xctl. At the next open, the method is correctly viewed by the xctl and xctl properties are accessible. NB : this behavior is the them with a non-saved property This is note good for all who have invest time to use XControls and build part of their development this feature. Hope that SP1 will fixe these issues...

Hello JG, This memory leak is really frightening! Using LV2010 gives the same behavior.I've came across memory leaks on XControl. I've pointed issue in the undo/redo mechanism. I've tried to apply workaround used to fixed my issue on your example. It was unsuccessful.I've played few minutes with your example. I've noticed the following (maybe you've already note): Replace "millisecond multiple" constant by a control Execute your code Change the value from 1 to 100 On my PC, when update speed is less than 50, memory increase. When it's more than 50, memory decrease and stay to the same amount. There is something strange, if it was a "simple" memory leak the memory shouldn't decrease. I think we need the lights of NI engineers.

You are right, I've never test this because I use an another way to load dynamic VIs. If you use Static VI Reference (see attachment) : - You don't have to add explicitly your dynamic VI in your build specification - You can rename your dynamic VI worriless - Your dynamic VI is hidden from end-users - code is the same in development or runtime As far as I've understood the question, I think this can fit with the issue. Regards,

If they are include in the EXE, I think they are in memory when the EXE is loaded. Try and let me know.

Hello, Have you try to use "All VIs In Memory" application property ?

As far as I know, if the dynamic process is part of the XC, you cannot use property or method owned by the XControl itself. More than a long text in a "crappy" english, I've attached a quick sample code (apologize for the messy G code, but it works) demonstrating what I've understood from your need. open the xctl file drop it in the New VI Front panel click on "Load // process" button send message from window to Xcontrol Let me know if it helps you. Regards XC.zip

This is definitely not a better way to do but maybe a workaround to try (I've implemented this solution in this XControl): Create an hidden cluster with a string and a variant in your facade VI Create an event case on Cluster "Value change" Give cluster reference to your parallel process Do "Value (signaling)" using the cluster reference to "fire event" Process action in the event case create in 2. String and variant allows you to implement multiple action and different data to process in your facade VI. Hope this can work for you. Regards Olivier

Hello, I agree the RT interest. As a first step, I've run DLL Checker (found here) on sqlite.dll and result seems to show there are some "bad" functions... However, we don't investigate more on this for now.Regards