Jump to content

jgcode

LabVIEW Tools Network
  • Posts

    2,397
  • Joined

  • Last visited

  • Days Won

    66

Everything posted by jgcode

  1. No last night it said 'Forbidden' (whatever http.status that is) - so I wanted to check if others had this issue. This morning it's working. So it could have been an issue on my end (mobile). Either way, all good now Thx.
  2. Ha! Looks like more like language barrier issues.
  3. I'll take any opportunity to razz you up
  4. I do the exact same thing - separating data from UI. I just like don't have issues with using locals to update a control when it comes time to push state data to the FP. There is one particular use case where I use them for the wrong reason but it's hidden - but yes you are right! However, normally I don't and don't need to break that rule
  5. Whats wrong with locals? I usually prefer them over references to update a control. However, I the rule I use is: one per control on each diagram (in the case of e.g. a state machine).
  6. The Shared Variable API is a bit more polished IHMO and recommend using it over DS as well - better error information etc... Although for reasons that escape me, I have used DS over SV-API for particular use cases in the past.
  7. I am not sure if that entirely true - you should be able to convert one datatype to another e.g. using a transitionary string and making sure the URLs are correct (as they are different).
  8. You can't do this. If creating plugins like this the Parent Class is the 'interface' so you should design it to use DD to add new behavior from Child Classes - as opposed to case structures as you mentioned. Is a Control or View an Instrument? I would say no - so maybe you should look at a different type of relationship. For example setting the e.g. view with the instrument data rather than inheriting from it etc...
  9. I haven't used it for a while - but if I remember correctly after the first read/write, it's a pretty similar speed. Should be pretty easy to test tho.
  10. I have added a new version to the LAVA-CR - v1.1.0.39 which contains the following new features: - New (): Added 'New Templates' feature - New (): Added 'Methods Sandbox' feature - New (): Added 'Refresh Icon' feature There are now in built templates I use - you can pop-up on a Class and select New Template to add a template to that Class If there are other common templates, please post and I can look at adding them By placing your own templates in the Templates Folder... ...You can script new Class Methods with them Pop up on a Class and select Methods Sandbox This UI will allow you to quickly script either the inbuilt or custom templates to create new Methods: The last feature allows you to pop up on a Class Method to quickly refresh a Method's icon without having to open the Class Properties Dialog and refresh all icons
  11. I have added a new version to the LAVA-CR - v1.0.0.23 This version supports LabVIEW 2011 and integrates into the LabVIEW Project Provider API The previous version was broken in 2011 as the Icon Editor API was not supported due to a switch to PPL 2011, so this functionality will not be included at the moment. I started playing around with the Provider API with Create Child Class which was a good plugin to start with. Along the way I found out that there was a limitation preventing me from releasing individual packages under one 'banner' so I will just be upgrading this package with new functionality in the future. And therefore won't be updating the Create Child Class package I posted - it will be done in this package. I've also moved the Rename LVOOP Labels code into this package as it more intuitive to use with the Provider. I need to brush up some stuff (examples etc...) but it this package is ready for feedback so please post So, in summary v1.0.0.23 supports: Rename LVOOP Labels Create Child Class Clone Method Right-click on a Class or Class Method VI to access the plugins: Go to Tools>>LVOOP Assistant to access other stuff: It also uses the Preferences code I OpenG'd up Enjoy!
  12. Actually you could add links, text, pictures or even code. And the Community could maintain and add to it as opposed to an individual someone. Currently code in the CR is reviewed which I don't see the point of (too formal as you say) and a dedicated forum seems a bit of overkill?
  13. In the past I've used .NET and the VI mje describes. I also using scripting to update a VI pre-build with the info programmatically. I generally use the latter approach for tools but it would work in an exe, it's just I have re-use code for the exe. I have posted a LabVIEW Project API and a build script on LAVA (sorry no link on mobile too) that you could look at as an example.
  14. I guess the choice will depend on if you want to track the code and related posts (comments etc...) or just the code.
  15. I suggest starting a document in the new knowledge base section - it would definitely suit this use case. You can turn a thread into a document but I would recommend creating a new document that contains links to these posts.
  16. Yes I did. Or, No I didn't (but then have forgotten ) Either way I like it! (unless I forget it again...)
  17. Nice one Jack - this works on the mobile version - excellent!
  18. The ability to programmably interact with layers in 2011+ would be nice too
  19. I really like this thread, as this is an area I am always trying to improve. I used to write config files like this (bar the input into class just output a cluster, esp for <2009 RT apps): The only thing I can add is that I found it easier using an enum as the key due to typos, esp when the number of keys get large, but that was just personal preference. Where variants can be used, I prefer to leverage existing APIs (such as OpenG) as it just so much less work to read and write to disk and extends the LabVIEW Config API by supporting other datatypes (e.g. arrays). Here is how I do configs with LVOOP. Mentioned in other threads I like to write the Object's private data to disk from within the Object. The data that is required to be persisted is stored in a non-typedef cluster. I usually end up having reusable Objects, application Objects (including general Config Objects) that I want to flatten to disk. These can be basic Objects, extended Objects, MFVIs/modules, arrays of Objects and Objects composed of other Objects - I am able to do this albeit there is a little more work for the last two. Typically I like to use a single ini file (as I like the format). I'll use a simple application as an example Here is the startup code for the application, it is quite simple and contains reuse modules (the purple banner object extends the blue banner object): Inside the second VI from the left (curves settings constructor) the structure of the file is setup (header, sections): When the Read VI (reuse) is called in the startup (third VI from the left) it performs checks, reads the header (meta data) and then the section data The section data is an override VI which extends the base case and is custom for every application. It calls the Object's read to disk method The reading is delegated to a File Interface (reuse) Object (not shown) which has a variant interface - it may not be the best interface but I found this was the easiest way for reuse. In the base implementation it uses OpenG ini format (abstracted under a few layers) as this is my preferred approach plus you can't really have abstracted Classes in LabVIEW etc... In the end this is what the file looks like, and it is minimal effort to create using the reuse modules: Additionally I can support versioning if required for that application in the future.
  20. v1.0.0.27 in the LAVA-CR includes the following features: Following up to mike_nrao's comment I have included a basic example of how to extend a Page and run code in parallel to the engine. To "do stuff" as opposed to just being static: The BD looks like this (from the example): New VIs that allow you to interact with the Framework (wraps dynamic calls). You can set the cursors and enable/disable the Ok button and FP Close X: In the <example> I have included a simple screen to demonstrate what these VIs do: I have added support for horizontal scrollbars. Only vertical scrollbars were supported in the original Framework, but I have extended it to work with both: I have added a Polymorphic API for launching the Dialog. It wraps loading from a folder:
×
×
  • Create New...

Important Information

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