Jump to content

Jeffrey Habets

Members
  • Posts

    193
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by Jeffrey Habets

  1. I have almost the same VI in my lib, I guess with very huge arrays of control refs (not very likely, I assume) this could be a bit faster since there's no fork on the array. The search loop is not any different..

    But do you use this VI inside loops? I guess you could just get the ref. once outside of a loop, it won't change during program execution..

    http://forums.lavag.org/index.php?act=attach&type=post&id=5387

  2. I'd like to post an update to this thread. Yes, there is indeed a way to create so called "pull-right" properties for XControls.

    Someone from NI informed me of a way that is not officially supported by them but none-the-less works.

    All you need to do is change the localized long name of the property to include the nesting. For Example: If you have a property called My New Nested Property 1 and you want the menu to appear like Mike->My New Nested Property 1, set the Localized Long Name to Mike:My New Nested Property 1. Colon is used as the separator.

    Ah, I actually was looking in the right direction for this.. I tried construct like Mike|NestedProp and Mike->NestedProp, but that didn't work. Obviously I didn't try the so obvious :. :thumbdown:

    Anyway, good work! :thumbup:

  3. Well, the more I work with Xcontrols, the more I realize that there is a SERIOUS lack of documentation or examples for them.

    Can someone shed some light on the Convert State For Save Ability and how the hell I'm suppose to freakin' use it? :(

    :lightbulb: Let me shed some light.. :)

    Normally when you save your VI containing the XControl (at edit time) the State data is saved with the VI. I.e. the State data is persistent as with native controls.

    Now let's say you have elements in your State data that you don't want to be persistant for some reason, you could implement the Convert State For Save Ability and use this to change what ever data needs to be saved with the control. Basically you could save whatever you want by wiring the data to Display State To Save.

    Now, when you use this, you need to implement code in the Init ability to read and convert back the Previous State to useable data for your XControl again.

  4. and helped out, many thanks. As mentioned before, the customer always wants something more. Now we need a programmable mark on the gage. In our application, a sequence of events takes place when the needle passes a certain point on the gage. The customer wants a mark to appear on the gage at the beginning of a test to indicate this point. This mark needs to be able to change position from test to test, but NOT during a test. I am including a test routine showing how the gage currently looks and operates. This is actually a somewhat simplified version of what we came up with before as I cannot stand too much front panel overhead. The gage must being updated (other computations as well) within a timed loop going at 100ms.

    I think you can simply add an extra needle on your gauge and use that as your marker. Popup on the control and select add needle. The datatype of your indicator will change to a cluster so you'll have to do some rewiring in the BD, but that shouldn't be a problem.

  5. I've used DIA in the past and still do sometimes, but mainly I use Endevo's UML modeller now. So I'll list them both here. I use UML mainly to model the class diagrams. If classes designed by me are to be implemented by others I might also use sequence diagrams to describe the interaction between classes.

    One other tool I've been wanting to have a go with is ArgoUML (http://argouml.tigris.org/), which is also opensource. No experiences with ArgoUML yet, so I won't list it here.

    Name: DIA

    Website: http://www.gnome.org/projects/dia/

    License: Open source, GPL

    Description: From the DIA site: "Dia is inspired by the commercial Windows program 'Visio', though more geared towards informal diagrams for casual use. It can be used to draw many different kinds of diagrams. It currently has special objects to help draw entity relationship diagrams, UML diagrams, flowcharts, network diagrams, and many other diagrams. It is also possible to add support for new shapes by writing simple XML files, using a subset of SVG to draw the shape."

    How Long: 4 years

    How Often: Some projects involving GOOP

    How Many: Just me

    Pros: It's open source and free to use. Easy to use, short learning curve. The diagrams are stored in XML!

    Cons: For people that are not used to Gnome or programs written with Gtk toolkit the userinterface might take some getting used to.

    Notes: There are code generation modules for DIA for several textual programming languages, but not for LabVIEW. This could be done though, since the diagrams are saved as XML data and are not so difficult to parse. I once started work on a tool to read the diagram data and create GOOP classes from it, but stopped working on it when Endevo introduced their UML modeller.

    Name: UML Modeller

    Website: http://www.endevo.se/content/view/10/13/lang,en/

    License: Commercial, I think it is about $500.00, but you'll also need their GOOP Inheritance toolkit if you want the benefit of code-generation.

    Description: The modeller is written in LabVIEW and thus integrates seamlessly with LabVIEW. It runs from the LabVIEW dev. environment and uses the Endevo GOOP Wizard for code generation from classdiagrams and reverse engineering to update your UML from the LV GOOP classes. I think the next version will also support native LabVIEW classes. Other UML diagrams like e.g. Use case, State diagram, sequence diagram, etc. are also supported.

    How Long: 3-4 years

    How Often: Most projects involving GOOP (Allmost all my project involve GOOP..)

    How Many: Just me

    Pros: Very easy to use, short learning curve. Integration in LabVIEW. Code generation and reverse engineering!! Developers take good note of user input to improve the tool.

    Cons: Not cheap, together with the Inheritance toolkit it's about $1700.00

    Notes: Despite the costs I still think the tools are worth it since the code generation and reverse engineering is quite a time ( = money) saver..

  6. Does anyone know how to detect the type of the inherited item?

    If I use a propertyitem label on a string control I get a label-reference, I haven't succeeded in determing the type using OpenG-toolkits. PJM private class generator doesn't know the classes as well. I have found out that the classID is 5 one of the low ones PJM hasn't identified.

    Does anyone have a clue?

    I'm not exactly sure what you're asking, but ClassID 5 is the Text class (GObject->Decoration->Text).

    Do you need the private parts of this class?

  7. do you think it is a lot of work to read all the properties/methods of a normal control and process this into properties and methods of an XControl? with scripting off course

    Then if you have a XControl consisting of several controls, should you build all the controls, or just some?

    This should be possible. I'm looking into it at the moment, so lets see what comes out. :rolleyes:

  8. I have to design a circle which can show the direction (such as: North, South, South West,...) and the needle which can move like the picture I upload.

    I use the Gauge Control but the max and the min line has a distance, therefore it can't display all the direction.

    Can you suggest some ideas for me?

    I really appreciate your help.

    You can grab the max value line of the scale with your mouse and pull it towards the min value. You get a gauge that does 360deg this way.

    You can also grab the min value to rotate the entire scale. This could be usefull if you want the 0/360 value at the top instead of at the bottom of the gauge.

  9. Your question Michael reminds me of one XControls related question of mine that still is unasnwered. Is there a way to inherit properties and methods of build-in LabVIEW control to the properties of an XControl at least in a case where XControl front panel consits of only one built-in control. The idea would be to extend the functionality of built-in control in a much a same fashion as one can extend functionality of a OOP class. I haven't found a way to inherit these build-in properties and methods but maybe some LAVA readers have... :rolleyes:

    This was for me also the first feature I searched for when the XControl was introduced. Saddly it appeared not to be possible. It would indeed be nice to have this feature in the future for at least the XControls that have only one native control embedded.

    For now, as a kind of workaround I just create a read property for the embedded native control's reference, which at least gives some kind of flexibility without having to re-implement common properties/methods.

  10. First to answer your question, the

    #ifdef __cplusplus

    }

    #endif

    is the closing bracket for the Extern "C" { part..

    I also tried pass and receive strings to a DLL but not succesfull. Can anyone tell me what's wrong with the following DLL?

    The reason why your dll call didn't work is that your return type is char and in the LV call library node you have it configured as pointer to string. The VI in the attached zip will work with your dll, I changed the return type of your function to U8. Also look at the comments I added to your .c file. There are faults in there too. (In LV you can compare strings that way, not in C. ;) )

    Download File:post-906-1166610996.zip

  11. You can already drop whatever type you want onto the queue/notifier refnums. Drag any control over the type display (the FPTerminal drawings) of the queue/notifier refnum, and it'll accept the control and update the type display. You can also popup on them and choose "Show Control" to get a more "datalog refnum" sort of view.

    If you create a queue of a typedef, the queue knows that it is connected to that tyepdef, and so when you update the original typedef, the queue is updated. There's no need for a second typedef of the queue itself.

    Stephen, you're the king.. :worship:

    I don't know why I never noticed this feature before.. I just checked and it is possible since at least version 7.1.

    So we now only need to put some refs in the control palettes to make them easier accessible..

    Thanks!

  12. Sounds like this might be a good candidate for an OpenG sub palette off the current Refnum palette. There should be a way to do this with scripting. Perhaps PJM's Private Class generator already has these. I'll check.

    The problem with these kind of refnums (queue, notifier, event, etc.) is that they also hold type information, so the refnum type changes as the element datatype changes. So there's not really one refnum-type for a notifier or a queue. :(

    What would be nice to have is if NI gave us 'empty' refnum controls for queues, notifiers, etc. in which we then could drop whatever control we want to be the datatype (analogous to what now is possible with the datalog refnum) for that specific object. This would certainly make life easier since now I have to keep two seperate typedefs (one for the data type and one for the refnum type) for every queue or user event I use in my apps. I'd like to see these two connected somehow.

  13. Nice, we learn something new everyday.. :thumbup: If both scrollbars are gone and you want them back, go to the VI properties -> Windows appearance -> Customize.

    While checking the pane properties I also noted that we can now select a picture to provide a background texture.

    Just to bad the 3D controls don't have an option to take over the background texture (e.i. blend in..). :(

  14. The master slave pattern you are using now is perfectly fit todo what you want.

    Reading you message, it appears to me that you are trying to put al your code in the toplevel VI. I think you should have a close look at your code (especially the analysis part) and try to refactor parts into sub-VIi's. Try to identify parts of the code that are logically nameable, decide on what inputs and outputs that part should have, and create sub-VI's for those parts. Use good discriptive icons for the sub-VI's.

    This should clear up your toplevel VI while still understanding what's happening, just by looking at the toplevel diagram.

  15. I'm dynamically registring for events, so I can choose for each xcontrol I can register for certain events.

    Now what happens is that IF a dynamic event is triggered the Display State (with the class) is reinitialized to it's default value, meaning my picture disappears.

    Does anyone else have seen this (It also happens when I don't use dynamic registring....)

    I'm resisting the urge to post code, since it's bad documented and quite complex (a class in an xcontrol)...

    Some code would help.. I'm not really sure if I know what you mean..

    Is it the actual "Display State In" control that get's an unexpected value? Did you probe this in the facade VI?

    I've been playing a bit with classes in XControls too and have seen some strange behaviour, but haven't been able to put the finger on the exact problem yet.. Need to play around a bit more with this..

    PS One question I should put my internal data off the xcontrol in the display state control right?

    Yep, that would be the way to go! And don't forget to notify LV of state/data changes through the action output.

×
×
  • Create New...

Important Information

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