Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


ak_nz last won the day on September 22 2016

ak_nz had the most liked content!

Community Reputation


About ak_nz

  • Rank
    Very Active

Profile Information

  • Gender
    Not Telling
  • Location
    Good Ol' New Zealand

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since

Recent Profile Visitors

1,365 profile views
  1. The method is static - you don't need a constructor node so try without that. The exception text isn't in a language I'm familiar with but I suspect it may be due to which thread is executing the clumps. Try also setting the VI execution properties for the enclosing VI to run in the UI thread only.
  2. I assume you're talking about a WPF app. WPF apps are normally launched via the static entry point App.Main() method, just like Windows Forms and Console apps (which by default specify a Main method in the arbitrarily named Program class). The contents of this method is normally generated for you by the compiler, and typically creates an instance of the App class, calls it's InitializeComponent() method followed by the Run() method. The default implementation of the InitializeComponent() method is parse your App.xaml, determine the startup Window class (in your case, MainWindow.xaml)
  3. We're not a small business, we're part of a large one. Guess there are benefits to such things after all.
  4. VM works best for me. We're lucky that we have covered the Client OS licensing part of things so it frees us up to create a VM per "project" if need be and to share the VM (+ change the product key). You need a good external storage to keep all these VMs backed up, but when transitioning back to an old project it just a case of copying it back over to the dev machine.
  5. Just a note that the C# code shown by the OP isn't magically interpreted differently by the C# compiler and will throw an exception at run-time just as rolfk says and for the reason he says.
  6. Out of interest it has to do with the version of the run-time CLR rather than the framework (which has the runtime as well as bas libraries etc,). LV2012 and earlier - use CLR 2.0 (which exists in .NET Framework 2.0 - 3.5) LV2013 and later - use CLR 4.0 (which exists in .NET Framework 4.0 and later - 4.6.2 inclusive) You can easily download the .NET Framework 3.5 offline installer and add this install to your installer as an action. You can run the offline installer in "silent mode" so that it installs or bypasses if installation already exists.
  7. My preference would be to have a "Set to Default" method of the class that initialises the object with reasonable defaults that you call on teh startup of your application. Then your settings UI can call methods on the object to tweak teh settings as the user desires. As a general rule I dislike the "Default Value" properties of controls because they can be very hard to control and enforce over the development lifetime of an application.
  8. Long and short your answer is what you suspect - there are several VI server methods that are not implemented in the run-time engine and are thus not available if you build an executable. The same issue crops up in other areas like build automation. The way I get around this is to use the IDE but automate the process via scripting. I have a build VI (happens to be a VI Package) that runs automatically via LabVIEW command line arguments that performs the necessary operations and then quits LabVIEW. Not ideal I know but the only realistic option I have found.
  9. Doesn't the toolkit use SharpSVN internally? You could probably manually over-write this assembly with the latest online and chances are it would work.
  10. TSVN Toolkit works fine in LV2015. The only issue I have found is that exposing the SVN icon states onto the Project Explorer items is a bit of a network hog - as a project grows increasingly larger (100s of items in the project) then project operations tend to suffer. But other then that I have found it a useful tool with SVN repos, especially when it comes to keeping files on disk and items in projects in sync (eg. re-naming).
  11. There is normally an idea of "interface" or "trait" that allows a class to say to callers that it implements certain behaviour. In standard out of the box LabVIEW, these ideas are only possible via composition rather than by inheritance. The GDS toolkit will allow you to create interfaces in a way but natively LabVIEW only supports single inheritance and has no notion of abstract classes or interfaces that exist only to enforce a contract for behaviour. Don't forget that OOP hierarchies are not about "things" they are about common behaviour in the context of your callers. if you find yours
  12. Are the .NET assemblies referenced in your project library in the source of the component prior to building a package? I have several components that use .NET assemblies - I have never copied them to the LabVIEW folder when changing source; they have always been in the source project folder or sub-folder. LabVIEW effectively adds this folder to the Fusion search paths when resolving assembly locations.
  13. In this stance your Cat and Dog hierarchies are actually different functionally - one Meows and the other barks. Your find Animal and logic after that presumes to work on any Animal - but Animal doesn't have a bark or meow. This is an LSP violation for the caller that expects an animal to do something specific. Your use case of the API (your example) is that the animal needs to make a sound - bark or meow is irrelevant. In this instance I think it is cleaner to: - Have a Make Sound method in Animal that Cat and Dog base classes over-ride to Meow or Bark. - if it is important to be abl
  14. We use VI Package Manager for this (vip files) and then deploy a single VI Package Configuration file (vipc) for the actual project that contains the correct version of the package dependencies. This way a developer can open the source and deploy the correct version of the packages.
  • Create New...

Important Information

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