Jump to content

Search the Community

Showing results for tags 'nightly builds'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help

Categories

  • *Uncertified*
  • LabVIEW Tools Network Certified
  • LabVIEW API
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
  • LabVIEW IDE
    • Custom Probes
  • LabVIEW OOP
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 1 result

  1. Hi, I would like to use TOOLHELP.DLL (logs crash source and state metrics) inside the application distributed to our customers and build a project management tool that will be written in G and is entirely open source (BSD) and Lavag community developed. The goal is: TOOLHELP.DLL will log the bug when the distributed application fails. Once the user checks for updates this log will be sent to a DB on a LabVIEW issue tracking tool that will be written by each of us in Lavag. The issue tracking will be written in LabVIEW and not in some external language and will handle multi user and multi projects over the net with time line and milestones organization. This project will handle basic requirements with reference to the relevant files. The manager could see statistics over the different project problems and stability. The project will run in the background and summarize how much time the user was working on each program and file (browser, office... and if it is LabVIEW then how much time was each vi being used) while taking into account mouse and keyboard actions and idle time. The project will be hosted on line so the community could work on it together and even add plugins (features like nightly builds, scripting tools and/or any other feature implementation in a different or better looking way) while maintaining best practice guidelines and use the project as a test case for new users. It might take a year since we all have other work to do. It doesn’t matter. The point here is not just building this specific tool. I could buy such a tool that will almost do what I want it to do and deal with the fact that it will never be perfect and that I’ll never be able to suite it to my exact needs. It doesn’t even bothers me that I’ll probably have to buy and learn to use several packages that each will cover some of my needs and none will handle my basic choirs like handling LV nightly builds. I could have also posted it as a LV idea exchange and wait for NI to implement it and ask me to pay for it. The point here is testing out a less individual and more communal tool development concept. Let me know what version of LV you would like to work on and I’ll load a starting point skeleton so we could start our block n’ wire session. Looking forward to see how this will come out, Dror.
×
×
  • Create New...

Important Information

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