Jump to content

Olivier Jourdan

Members
  • Posts

    152
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by Olivier Jourdan

  1. We have just post an additional free package (this is a beta version) to SQLiteVIEW on the SAPHIR - toolkits community.

    This package intend to add the ability to write (and read) cluster to SQLite database as OpenG Variant Configuration File functions do with configuration file.

    You can find more information here

    Regards,

    Olivier

  2. Hello,

    I recently add the following ideas to improve XControl in LabVIEW Idea Exchange.

    1. Polymorphic XControl
    2. undo step management in XControl
    3. Add "Get focus" facade VI Event to XControl

    Your thoughts (and kudos if you think it deserves it) about these are welcome.

    Also, I encourage XControl fan to post on the idea exchange (fell free to add your idea to this thread) to see this awesome technology improved by NI

    Regards

    • Like 1
  3. Specifically, I am developing a library of XControls and want to modify the Representation, i.e. change the XControl from a DBL to, say, a U64. O

    Hi DaveC,

    as far as I know, this is not possible in LV 2010 and I don't think this will be available LV 2011. This would be definitely a great feature to add to XControl.

    Your are not the only one to expect this feature --> http://forums.ni.com/t5/LabVIEW/Polymorphic-XControl/m-p/1161937

  4. 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.

  5. I don't think there is anything inherently complicated about creating Xcontrols any more than creating a class. The issue is though, is that you cannot inherit from a pre-existing control (class?). This is what makes it not worth the effort since even for a simple control (a numeric for example) all the existing properties and methods have to be re-written Instead of just writing the additional functionality.

    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 :)

  6. One option is to use a Issue tracker (or bug tracker), like Mantis.

    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.

  7. Yup. But you can't print it out and give it to an underling biggrin.gif

    You're right, but an underling is should be able to do "CTRL+F" wink.gif

    To be fair, this solution is quite simple and have some lacks but it is also quite easy to use and to maintain.

  8. Or I could reference an external buffer (i.e. using a DVR)? - but didn't want to do that.

    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 rolleyes.gif

    Regards

    • Like 1
  9. 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

  10. 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 :

    1. Create an XControl
    2. Add a slider on facade.vi FP
    3. Add beep.vi in a "0" case, outside the while loop, link selector to while loop "i"
    4. Add "Slide:Value change" event case
    5. Add "Slide:Mouse Enter" event case
    6. 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

  11. Hello,

    The choice between a queue, and user even depends upon the function of the main process. (ie. polling, or non-polling)

    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

  12. 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.

    • Like 2
  13. Hello,

    issue with properties seems to be more frightening...

    Seemingly, create a method doesn't work as it's works in previous LabVIEW version.

    1. New method created is view as a simple VI by Xctl
    2. If you try to open XCtl properties you obtain the following messages
    3. post-853-0-88875200-1289819327_thumb.png
    4. post-853-0-01427600-1289819359_thumb.png
    5. 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...

  14. 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):

    1. Replace "millisecond multiple" constant by a control
    2. Execute your code
    3. 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.

    • Like 1
×
×
  • Create New...

Important Information

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