Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About smidsy

  • Rank
  • Birthday 03/12/1987

Profile Information

  • Gender
  • Location

LabVIEW Information

  • Version
    LabVIEW 2014
  • Since

Recent Profile Visitors

1,176 profile views
  1. I am happy that they finally realized, that the NXG idea is a way far from being somewhat practical or pragmatic. I am very sad it took NI so long to understand it. If I were NI I would probably go for changing the underlying engine and software stack and would rewrite LabVIEW completely, if I realize that the LabVIEW source code has reached it's end-of-life state and is very hard to maintain. This was one of the driving forces according to the information I got from NI during CLA Summit 2019. But I would never ever change (at first) the interface to the Users and to Developers and r
  2. Hi, You can actually typecast your DVR reference to U32 value (pointer) and back. You can store this U32 number in a helper class, that will represent your API. Or, if you decide to go with a helper API class, then you actually don't need to typecast it to U32 - just store the DVR inside the public API helper class:
  3. Posted also on forums.ni: http://forums.ni.com/t5/LabVIEW/Excluding-instr-lib-folder-from-Project-Save-For-Previous/td-p/3760288
  4. Hi, I would like to automate downgrading process for few LabVIEW projects from LV17 to LV14. I use Project.Save for Previous method and it works fine for simple projects. It ignores everything that lives in vi.lib (KB). But if I have a project that refers to toolkits located in instr.lib like instrument drivers, NI-DMM or NI-DCPower, saving for previous exports some of them to my destination folder. Interesting fact: I receive a warning, that NI-DMM and NI-DCPower were not converted (good news), but niModInst (part of NI-DCPower) was! And, of course, third-party instrument drivers (P
  5. Yes, I agree, if something isn't right with a third-party toolkit, and you need to fix it quickly, you would probably want to look inside instead of exchanging emails with a support team. An then you open the block diagram with your favourite password cracker and realize, that the paid toolkit code is ugly and dirty, and you can definitely make it better. You copy and paste (or just take some ideas from the code), adjust it here and there, and reuse. It is not that bad in general, but my boss would not be happy Good point. Not sure that this is enough though. Will inlining make
  6. Hi, I would like to implement a Run-time license checking mechanism that will enable or disable some parts of my LabVIEW API depending on a license status. After reading numerous discussions here on the forum (We need a new password cracker :( , Low level VI data editor (warning: not for production use!) , I found some more hidden INI keys, Password Security in LabVIEW) I realised few things: - reverse engineering in a LabVIEW-related field seems to be a doable task for some smart people, - password protection on block diagrams does not protect your IP, it is more of a "r
  7. Hi Aristos, Thanks, good to know this! Other questions (very trivial I guess) that came to my mind: 1. Is it possible to configure the size of a Panel? Restrict resizing? 2. I opened one of the examples and zoomed out. Why do I have the white space around my UI and then the gray space (I suppose the limits of my panel)? 3. How should zooming feature on front panels work in a compiled application? Would it be possible to control it programmatically (restrict or allow zooming, zoom to a specific value)? Am I alone seeing new panels a little bit strange?
  8. I feel uncomfortable with this too. But maybe I just need to get used to it. This is a screenshot of Microsoft Visual Studio designer: When designing in Visual Studio, you can choose between WYSIWYG, XML or split design modes. It makes sense and it is very practical from my point of view. You can zoom in or zoom out on your application window, and you get the perspective of how it will look like. Is it possible to do the same in NXG?
  9. Tim_S, Yes, I agree, this would be the best solution to the problem with having multiple apps referring to one set of Core PPLs. Each application build process though needs to copy all static Core PPLs to its own ..\Shared\ folder.
  10. Hi Tim_S, Hi smithd, Yes, that is what I did. I have my parent classes from PPL dropped on my block diagram in the application. I have also few child classes that are dynamically loaded using the mentioned Packed Library palette. Parent classes are stored in few PPLs (Core PPLs). Child classes are also stored in few other PPLs (Plugin PPLs). They are loaded dynamically. I plan to have more than one application on one PC that uses Core PPLs and Plugin PPLs. I also plan to update the functionality (fixing bugs, extending functionality etc.) in both Core and Plugins PPLs in
  11. Hi All, I have an application that uses PPL (Packed project library). During the build process of my application LabVIEW copies the PPL to build/My App Folder/data. I can run the application afterwards. If the PPL is deleted or moved later from this ../data/ directory I no longer can run the app. Is there a way to dynamically link and load PPL from another location? I've tried using viSearchPath for this but unfortunately it doesn't work. Thanks, Nikita. also posted here http://forums.ni.com/t5/LabVIEW/Create-a-link-to-PPL-Packed-Project-L
  • Create New...

Important Information

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