Jump to content

Francois Normandin

Members
  • Posts

    1,209
  • Joined

  • Last visited

  • Days Won

    46

Posts posted by Francois Normandin

  1. Now comes the fun part - creating getters and setter to access the members of "private data". I also intend to do that with templates, unless someone has a better idea...

    Br, Mike

    Actually, I might have something for you as well...

    lava_lib_lvclass_api-2.0.0.15.vip

    Try this version of LVClass API. It is not for immediate release to the CR because I haven't had time to fully test it myself (especially the "Copy Library" function), but the basic functions are stable.

    Check the "Private Data" Subpalette.

    2011-07-06_0821.png

  2. François,

    could you alter the set to move the boolean text ouside of the boolean image?

    Hey Ton,

    I made a quick fix VI. It should move the boolean text to thye top right corner, outside of the control. Also, it will unlock the boolean text so you can move it.

    It will correct the whole VistaStyle Buttons hierarchy in the UI Tools folder.

    Most likely, I will not have time to make the modification to the set and rebuild the package during the week-end...

    François.

    CorrectBoolTextPosition.vi (saved for 8.6)

  3. François,

    could you alter the set to move the boolean text ouside of the boolean image?

    post-2399-0-95684000-1301321137_thumb.pn

    Ton

    Ton,

    I haven't seen your post before today. I'll work on it, hopefully this week-end.

    Hi

    Can You tell me that How you create the image file to create such control. ?

    It really work for me.

    Regards

    Prabhakant

    Hi Prabhakant,

    you can install the "Control Class add-on" and it gives you an API for doing what you want. There's also a small program you can launch from the Tools menu that gives you an interface for it.

    There are some videos in the discussion thread.

  4. I cannot reproduce the good wire on the Equals prim in LV 2010.

    Do you see anything that I have different from what you were doing?

    I bet that you have SP1 installed... I haven't. Before tackling this issue with a piece of code in CR, I had not used LV2010 since last NI Week. So I guess you guys corrected the bug with the 2010SP1 release.

    And in the VI you just sent, can you just use parent events and send the appropriate data later?

    I would normally, but this is part of a framework that the user must simply feed the class type and the rest is done automatically. So in an ideal world, what you propose is pretty much the right thing to do to make sure my paradigm doesn't crash LabVIEW, but here I can't because the user can fork create his own events in parallel, and he might receive the events I send with my framework.

    I'm refactoring the whole framework. Hopefully it will be even better because I will also circumvent the "bug" misunderstood by-products of an intended by-design behavior of events that cursed Justin at the CLA Summit, which I just read about after listening to Mickael's podcast...

  5. OK, the reason it breaks the code is that I used a technique that could be unsafe if used otherwise. I results from a bug in LV2009, that was not announced (to my knowledge) but that has been corrected in LV2010.

    I have good reason to believe that the code is safe in LV2009, if you use the Handler as described. However, I cannot garantee that it will not crash as shown in this thread.

    I've posted an example over there, derived from AQ's explanations, as to how it can easily lead to stop LabVIEW (or crash it).

  6. You should never be allowed to cast an event of child as an event of parent. Consider a hierarchy of Parent, which has two children named Son and Daughter. I create an event of Daughter. I register it with an Event Structure, which now has a Daughter type output. Then I cast the event refnum as an event of Parent. Then I use Send Event to fire the event, but the data I give it is of type Son. The son data is transmitted and comes out of a Daughter terminal in the Event structure. This is a problem because the private data of Son will be incorrectly interpreted, and you may crash. Yes, this metaphor leads to some terrible jokes. But the crash that occurs is no joking mater.

    The reasoning makes sense to me now. Thanks for clearing that out.

    I put up an example which I think shows how I used it (safely) and how it can be used as you describe and crash LabVIEW. Basically, if I index the array of event refnums, I'll always propagate the data as a "Parent" and never encounter the situation above. However, if I fork the child event and use the arrayed one to transmit the data, then I can cause LabVIEW to stop.

    Obviously, I'll have to find another way do achieve what I want. The potential is too great for the work-around you've suggested to be implemented in shared code.

    Test Event 2009.vi

  7. Something fundamental seems to have changed between LV2009 & 2010 about Events Refnums and OOP.

    This arises from investigating why my code breaks down in LV2010 (LVOOP Event Handler in code repository).

    In LV2009, it used to be possible to make an array of events where the event refnum of child classes could be carried on the wire of the parent class event refnum.

    This has changed in LV2010 as it is no longer possible.

    Digging a little on this issue, I found out that the "equals" primitive has also changed behavior between versions.

    It seems that if the datatypes can be arrayed, it should also be allowed to compare them, right?. Granted, it should still return "false" if the refnums are not pointing to the same objects, but why the broken wire in 2009? This behavior has been corrected in 2010 so it seems that LV recognized that these are of the same type (or at least in a parent/child perspective). So why would it be impossible to make an array to these?

    At least, we can still pass a child object on the parent event refnum... and not a parent object on a child event refnum (consistent).

    Anyone can confirm that this is a bug and not expected behavior? And obviously, one version has a bug... which one? Both?

    post-10515-0-70206400-1303307528_thumb.p

  8. Again, this is by design and is a technique I learned in the LVOOP class. Why is this a bad idea? When you say each class should do one thing, I thought that is what it was doing. Each channel class sends and receives messages. Each message class acts on a message. Isn't this basically what the factory pattern does?

    I suppose one improvement would be to make a single channel class and them implement some way to create channels with a method in that class. My current design uses the channel class itself as the differentiator between the channels. Perhaps I could make a friend class to hold the common components of the channel class. But, I still need a way to differentiate channels from each other so messages automatically go to the proper process.

    What I meant was that you should have one class per message type (10 message types = 10 classes), not one class per message type for each channel (10 message types, 5 channels = 50 classes).

    Like Daklu pointed out, this is not what you did but rather the additional classes I saw in your hierarchy were for testing the functionalities.

    I'm home today, so still can't have a look at the code. I'll refrain from further comments until I do.

  9. That was my first thought too, but it's not correct in the general sense. Channel_A_SendToB.lvclass is message sent by the UI loop to the Channel A loop telling it to send a message to Channel B. It's just a way to test the ability to send messages between channels A and B. I don't think it's something you would do in a regular application.

    OK, I was afraid I might be misinterpreting the disk hierarchy. Without looking at the code (no LV2010 at home), I was prone to make a wrong judgement there...

  10. Added and improved the first version.

    John,

    I could not test it because I lack LV2010 at home. Will take a peek at work next week.

    However, I can comment on the data structure based on the class directories.

    It seems your implementation requires you to create a new class for each new message type, and do that for each new channel you create. I don't think this is a good way to use the class hierarchy. Your channels and your message types are not separate entities as they should. Each classes is supposed to do one thing. In this case, either act on a message received, or send a message to specific channels. Not both.

    I might be completely off since I only comment on how your file structure is represented, but it looks like that if you were to create "Channel C", you'd have to also create new classes named:

    Channel_C_SendToA.lvclass

    Channel_C_SendToB.lvclass

    Channel_A_SendToC.lvclass

    Channel_B_SendToC.lvclass

    For Channel D:

    Channel_D_SendToA.lvclass

    Channel_D_SendToB.lvclass

    Channel_D_SentToC.lvclass

    Channel_A_SendToD.lvclass

    Channel_B_SendToD.lvclass

    Channel_C_SendToD.lvclass

    And it gets ever longer for each new channel you wish to create.

    To use wisely the OOP strenghts, you'll have to devise a way to have only one class to create if you add a new channel, ad one class to create if you add a new message type.

    I'm sure there's a way to do that using Queues. Like you would say, these classes need to be decoupled. ;)

  11. Hi John,

    The way I've gone about this with OOP in the past is to use Events. Now, I don't know how well this solution would work for you, but basically, it's a framework by which each loop would subscribe. The framework is based on very simple code I put in the CR a while back: LVOOP Event Handler.

    If you're not talking about lots of data (high streaming), it could be worth exploring. I've done an example (attached code) for which you'll have to install the LVOOP Event Handler package for it to work.

    Messager.zip

    In essence, it takes a message hierarchy with a single dynamically dispatched VI to handle each cases, plus let's call it a "Loop" hierarchy to run each loop asynchronously. The parent Loop.lvclass will take care of registering each loops in the Event Handler. Then each loop needs to be a child class of this common ancestor. The only code that needs to be duplicated in the child is the way to talk with the Event Handler (3 event cases). It's all controlled with a "Global Stop" that is part of the Event Handler framework.

    post-10515-0-61082100-1301602031_thumb.p

    Each loop calls the parent "Run.vi" that will initialize the messaging events for each loops. It does it by scanning all available loops classes on disk. Plus, it creates an event to dispatch a message to all active loops. This should create n*(n+1) events in the handler.

    post-10515-0-07221800-1301602617_thumb.p

    Each loops overrides Run.vi, in which you have the event management plus you put your normal code. The events cases are "Global Stop" which gets the signal that the main VI has called for a shutdown, "Handler Activity" which gets called whenever a new loop is created and has added new registrable events and finally, "Subscribable Events" by which you will get the message when generated by another loop.

    As you can see from the project layout, the hierarchy is very simple. Copy one of the loop child classes and modify the Run vi. That's it.

    post-10515-0-45856600-1301603104_thumb.p

    <object id="scPlayer" width="1376" type="application/x-shockwave-flash" data="http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/jingh264player.swf" height="818">

    <param name="movie" value="http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/jingh264player.swf">

    <param name="quality" value="high">

    <param name="bgcolor" value="#FFFFFF">

    <param name="flashVars" value="thumb=http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/FirstFrame.jpg&containerwidth=1376&containerheight=818&content=http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/quick_demo.mp4&blurover=false">

    <param name="allowFullScreen" value="true">

    <param name="scale" value="showall">

    <param name="allowScriptAccess" value="always">

    <param name="base" value="http://content.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/">

    <iframe type="text/html" style="overflow: hidden;" src="http://www.screencast.com/users/normandinf/folders/Jing/media/86863818-b881-4dc1-a83d-b23f866aebde/embed" width="1376" frameborder="0" height="818" scrolling="no"></iframe>

    </object>

  12. I take it that there is no way to hide the second column though huh?

    If you resize the MCL, you can hide the data by showing only the first column.

    However, if you want to keep it separate, you can make an index in a functional global variable. Store the data associated with each listbox element in the FGV and retrieve it on demand whenever there's a value change for the listbox.

    • Like 1
  13. Another option that I have looked into that I haven't quite figured out how to do yet, if it again is even possible, might be to use a multi-column list box and instead have the item name in one column and the value in the other; however, I haven't found out how I can select the second column of the same row dynamically, nor have I found out how to hide the second row (the value row) so the end user doesn't have to look at it.

    To retrieve your data in the second column, use the "Item Names" property and index both column and row.

    post-10515-0-90408600-1299690677_thumb.p

    • Like 1
  14. Hi François,

    congratulations!

    I've got one question, where was your kilt made? My aunt in Canada (Hamilton) works in a place where they hand-made purpose fit kilts in traditional style. Could it be one of her's?

    Regards,

    Ton

    Hi Ton,

    my kilt was indeed made in Ontario (don't know which city) and rented (yeah, way too expensive to buy, although I have regrets...) through a tailor in Montreal.

    The guy is retired and closed his boutique downtown Montreal, but still does some business from his home because of nice guys like me who still want his business!

    So it's entirely probable that he had it made in Hamilton, although I have no way to find out. Perhaps you can ask your aunt if she made a "Sons of Scotland" kilt for a January delivery. There must not be that many at any time period... 9-yard kilts are not that common.

×
×
  • Create New...

Important Information

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