Leaderboard

I also want to focus on real world work and not exams. For me the most challenging part was to get a software engineering around the code. I rely a lot on hardware, with failures, delays and so on while getting presented must-have-specs last minute. Here some ideas: * Design patterns as noted above, not only OOP but also 'LV-native' solutions (plug-ins, subpanels, AEs). At takes a lot of time and a lot of failures to really get into that. But once you have it, it makes your day. You will start modelling/designing instead of just coding out the specs. And at first, you will produce not working code but 'abstract code' (the classes where you will derive from, or a set of templates). Which of course enriches your reusable library. The other side of this, when the tide of workload is low, you are still busy getting all well documented for the next project. I don't think that this is easy, it's the art. And I'm still an adept... * All kind of methods come in here, from 'uml' to 'test driven developement'... * Have your code accessible. A big range with many open questions to me. The issues range from accessing the nice reusable concepts when I'm on customer site to tracking back which delivered projects might suffer from a certain bug. Have this data accessible when management asks... SVN is a helper here, bug trackers as well, have some server access is also important. *Bug trackers are cool anyhow. They give you a tracability of problems, can produce paper for some meetings. Most important for me was that they help me to jump from one project to the next (and they are team-wide) * Automating your process: you can have a greate time coding all kind of tools to speed up your process. Automatic unit tests are a success story. There is so many ways for an engineer to go further. And the ultimate goal is to get the boring jobs done as fast as possible. Enjoy... Felix

Thanks Ben - I'm really glad you said that - it means a lot to me

Use Events and the menu reference created on right-clicking a control.