Neil Pate

That sounds like a fantastic opportunity, I am sure you will smash it out the park. To infinity and beyond!

I normally place a small transparent decoration over the control and this fixes it. Especially useful for tables where you are updating a reasonable amount of text.

RAM is virtually free these days. As much as I love and absolutely strive for efficiency there is just no point in sweating about several MB of memory. There is no silver bullet, if I need to do multiple things with a piece of data it is often so much easier to just make a copy and forget about it after that (so multiple Queues, multiple consumers of a User Event, whatever). It is not uncommon for a PC to have 32 GB of RAM, and even assuming we are using only 32 bit Windows that still means nearly 3 GB of RAM available for your application which is actually an insane amount.

No need to apologise, it did not come across like that at all. There is no rule that says you have to update your entire GUI every time a big chunk of data comes in. Its perfectly ok to have the GUI consumer react to the "data in" type event and then just ignore it if its not sensible to process. Assuming your GUI draw routines are pretty fast then its just about finding the sweet spot of updating the GUI at a sensible rate but being able to get back to processing (maybe ignoring!) the next incoming chunk. That said, I normally just update the whole GUI though! I try and aim for abou

My consumers always (by design) run faster than the producer. At some point any architecture is going to fall over even with the biggest buffer in the world if data is building up anywhere. User Events or queues or whatever, if you need lossless data it is being "built up" somewhere.

No, not at all. My producers just publish data onto their own (self-created and managed) User Event. Consumers can choose to register for this event if they care about the information being generated. The producer has absolutely no idea who or even how many are consuming the data.

I exclusively use events for messages and data,even for super high rate data. The trick is to have multiple events so that processes can listen to just those they care about.

if you can get this all done in C++ in a few days I am mighty impressed 🙂

Well now you are really getting in the need for a proper architecture with HAL and clonable/re-entrant actors and stuff. Not something that can be easily described in a few sentences.

You don't really need to worry about performance of the GUI anyway until you are getting into real-time updating of graphs with hundreds of MB of data. Even then it can be done if you are careful.

You do use the same "normal" controls in the class private data as you would in your GUI. This is 100% ok and you can use whatever you like as they will never be visible at runtime, they are just a visual representation of your data types. What you choose to show on the GUI is totally unrelated to what data you choose to have in the classes.

I especially like the bit where it locks up my PC so hard that even the mouse stops responding.

that is nice but I found it way too heavyweight to use regularly. My debugger is built into my application and can be used even in the exe

A simple way I have found which works quite nicely is to get the clone to register itself with some kind of repository (FGV). I then have another tool which reads from the list of running VIs and can do stuff like display status, open block diagrams etc.

Have you tried GitKraken? I know every harps on about how the only way to use git is from the command line but I don't actually think that is a good way to get to know something as complicated as git. Sure, move onto to the command line but don't start there. Learning a new VCS should happen slowly and mostly painlessly, who has the time to spend getting intimately acquainted with a new tech that does not actually help get the bill-paying project out the door?