Jump to content

John Lokanis

Members
 View Profile  See their activity

  • Posts

    797

  • Joined

  • Last visited

  • Days Won

    14

 Content Type 

Everything posted by John Lokanis

  1. John Lokanis
    If you want to do this programmaticly, then take a look at the NI Web Service Server in the code repository. There is a VI in there that uses .NET calls to do this for you. Feel free to use that in your project. Only works with Windows, however...
  2. John Lokanis
    SSL was added with LV2009. I have yet to upgrade to the new version. Once I do, I will investigate how SSL integrates into this tool and post a new version. Hopefully, I will get to this in the next few weeks...
  3. John Lokanis
    Cool. I wrote a VI years ago that does that same basic operation and I use it everywhere. I wonder how many other wheels we all have reinvented...
  4. John Lokanis
    What I meant is if you wish to 'hide' the SEQ implementation in a generic set of VIs that can be reused and simulate dynamic memory access, then you must use a variant as the queue data type. This is because you do not know the data type of the element you wish to store until you use these VIs in a program. And you cannot make this polymorphic because you will likely want to use a complex typedef'ed data type. Therefore you must cast the data you get from the SEQ to the specific datatype for you implementation. If this is true, then yes, DVR offer no advantage since their reference carries the specific datatype of the data stored within the DVR reference wire. This is too bad because it means they really are not pointers. A pointer does not (and should not) know what it points to! At least they are a bit cleaner than SEQs but I guess they offer no new functionality after all. Bummer.
  5. John Lokanis
    How about we simplify it and call it G++ ?? Personally, I like calling it Lab-voop, as in: "I am learning to write Lab-voop code in LabVIEW."
  6. John Lokanis
    Yes, you could certainly do this, but then you must store the queue data in a variant and cast it back to it's native type after accessing it. (assuming you want to build a set of generic helper VIs to do this and want to be able to pass 'any' datatype using these functions.) I don't have LV2009 installed yet, but my understanding is the DVR reference is a single static datatype but it knows what it is storing. So, you would be replacing the variant in the queue with the DVR datatype and then when you need to access the data, you would use the inplace structure that could decode the data in the DVR into its native type without having to do a cast. It's a minor savings but let's you skip the typedef for the data you are passing as well as leading to cleaner diagrams. Of course I could be wrong... Anyone want to test this? Does the DVR carry it's datatype on the wire or is it stored in the memory where it points to? -John ps. sorry about your lack of TIVOness. Honestly don't think I could live without a DVR anymore (the original kind, not the LV data type).
  7. John Lokanis
    If you really want named DVRs, just store your DVR in a single element queue and then use preview queue to retrieve it. You could put together a very simple set of VIs to implement this. I used to do something similar with single element queues and variants. Be sure not to destroy your DVR without freeing the queue or you might end up with Totally Invalid Value Objects, or TIVOs.
  8. John Lokanis
    Yes. Not ready for prime time. When it is delivered, it will hopefully have enough functionality to be useful...
  9. John Lokanis
    Too bad you cannot select multiple probes in the watch window and view them in the Probe Display frame simutaneously (with enough screen real estate). Perhaps this is a good suggestion for the Idea Exchange!
  10. John Lokanis
    Be careful or this might happen to you:
  11. John Lokanis
    Many of the presenters at NI Week promoted the LabVIEW Idea Exchange here. I have been reading, voting and posting to the idea exchange for awhile and just posted several new ideas/complaints that I thought of while attending NI Week. I challenge all LAVA members to visit the exchange and vote for the ideas you agree with (especially mine ). And if you don't agree, post a comment and tell me why! Then post your own ideas so we can all vote of them too. The more feedback we give, the better LabVIEW will be in the future. -John
  12. John Lokanis
    I didn't know about that one. I like it. I just threw mine together in a few minutes after this screwed me up one time too many. I should have searched for an existing solution. Oh well, there is always more than one way to skin a VI, I guess... Done! Go vote for it if you like the idea!
  13. John Lokanis
    Well, yes. What you describe is not the point of web services in LabVIEW. If you want to understand the basics, NI has several help articles on their site to get you started. What I am trying to do with this project is help an advanced developer take their web services and deploy them to a run time target. This was a bit of an after thought on NI's part and is therefore not straight forward. Since I suffered through the issues, I am trying to share that knowledge here to help others avoid the same pitfalls. In addition, I am providing some interesting uses of web services that are non-traditional but make them valuable to LabVIEW developers. -John
  14. John Lokanis
    Good thing I looked at this. I didn't realize the BBQ was at a different place than last year!
  15. John Lokanis
    As promised, here are the slides from the presentation. I think the topic was a bit advanced for some attendees, however. I got a lot of glazed looks when I tried to explain how important it was to understand application instances when using web services. Maybe I will get to present this or an updated version at NI Week 2010. Unfortunately, the slides don't have a lot of details and are more of an outline of my presentation, but maybe you can get something useful from them anyways. -John Web Services in LabVIEW.pdf
  16. John Lokanis
    I never thought of that! Good idea. I will try that in the future.
  17. John Lokanis
    Have you ever been editing a bunch of VIs in your project and then decided to run the main VI to see if the edits worked, but you left a modal dialog VI front panel open somewhere? The result is it becomes frontmost, but is not actually running so you are stuck because you cannot get to your main VI UI and you cannot interact with the modal VI either. I do this all the time and it just ticks me off. So, I threw together this simple VI to avoid all that. I drop it down on the block diagram of my main VI so it runs first. If this happens to you, give this a try and let me know what your think. -John Stop on Modal VI Open.vi
  18. John Lokanis
    Maybe next year. I am only presenting at the local users group now. But, I have some ideas for a few presentations at NI Week 2010 so we will see if any get selected. BTW: noticed that I spelled 'radio buttons' as 'radial buttons' in the description above. I guess technically since they are circular, they are 'radial' in appearance...
  19. John Lokanis
    Just a reminder that my presentation on LabVIEW web services for the Seattle LabVIEW Users Group (SLUGs) is tomorrow! I will post the slides on Wednesday. Still editing them!
  20. John Lokanis
    I'm @jlokanis
  21. John Lokanis
    I do something like this, but in my case I *do not* want to have the plugin share sub-vis with the main app, even if they are really the same VI. This is because I may have 'upgraded' that sub-vi after releasing the main app and broken backward compatibility. So, I use OpenG builder to build my plugin LLB and namespace all the VIs so they never share with the main app. The only exceptions to this would be functional globals that I want the main app and the plugin to share. In that case there is a tab in the OpenG builder to exclude a VI from the LLB (forcing the plugin to use the one in memory from the main app). I find the easiest way to build something like this is to have a project with all my plugin code in it and one VI that is never run, but has all the VIs needed by the plugin on it's BD (top level VIs and any dynamic VIs). I call this the 'static links' vi. This is the only VI I include in the OpenG builder setup. By doing this, it picks up all the required VIs and puts them into the LLB. Beware including or not including the vi.lib VIs in your LLB. If you don't then you will have to hope the main app included the ones you need. If you do, you will add to the overhead of your LLB and will need to include any external DLLs those VIs use (a good example for me was using Fieldpoint VIs in my plugins but not in my main app, leading to many un-fun build issues/bugs). OpenG Builder is a great tool for solving your problem. I wish NI had some of this functionality natively. -John
  22. John Lokanis
    Not sure what is causing this but here are a few things to try: 1. what is in your Error case? Do you pass the queue ref through? 2. Try using a shift register for passing your ref through the loop. This is just good practice and is very important in FOR loops because if the loop does not execute and you don't use a shift register then the output tunnel will be NULL. Not sure if timed loops can also do this. Normal While loops cannot since they always execute once. 3. Are you sure you are not stepping on the queue somewhere else with a force destroy set to true? 4. Can you post more of the code for us to look at?
  23. John Lokanis
    Polling...bummer. I really wish they would give us a mouse scroll event!
  24. John Lokanis
    What event are you using to trigger this code?
  25. John Lokanis

    958 downloads

    Find Text v1.0.0 Copyright © 2009, John Lokanis All rights reserved. Author: John Lokanis LAVA Name: jlokanis Contact Info: Contact via PM on www.lavag.org LabVIEW Versions: Created and tested with LabVIEW 8.6.1 Dependencies: None. Description: This project contains the Find Text.vi and supporting subvis. The Find Text.vi displays a dialog allowing the user to search a text display for a specified string. A reference to the string control must be passed in. When the string is found, the calling VI will become front-most so the string can be highlighted. If the string is not found, an error message is displayed. Searching starts from the cursor location in the text control. You can change the search direction using the radial buttons. The VI will remember previous search strings inside the combo box where you enter the text to find. If you pass in a caller reference, this will be used to center the dialog. Otherwise, the VI will attempt to find it's caller in the call chain and center on that. If you call this VI dynamically, it will center itself on the primary monitor if the caller reference is not passed in. Instructions: Open the 'Example - Find Text.vi' and run it. Select the Find menu function or press Crtl-F to open the Find Text dialog. Known Issues: None Acknowledgements: None Change Log: v1.0.0: Initial release of the code. License: Distributed under the Creative Commons Attribution 3.0 (http://creativecommons.org/about/licenses) See link for a full description of the license. Support: If you have any problems with this code or want to suggest features: please go to www.lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the "[CR]NI Web Service Server" support page. Distribution: This code was downloaded from the LAVA Code Repository found at www.lavag.org
×
×
  • Create New...

Important Information

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

  I accept