#6 Simplify MidiTest demo code ?

[jtbalogh]

Simplify MidiTest demo code is a good suggestion.
Investigating easier ways to use the multithreaded
scrollbar, multithreaded textbox, status boxes, progress
bars, etc. so that the code does not look crazy. Also
more classes and fewer public variables could help group
features closer together. In most cases, it is more
practical to strive for ease of use and sacrifice speed.
Demos look worse when code is not modular.

Unfortunately usercontrols in VB have had lots of
problems and could not always help encapsulate
features reliably. Adding separate active-x projects to
handle features affected all windows programs, access
was even slower, and was a hassle to maintain multiple
projects just for one demo.

Just a thought.
Self critique by jtbalogh

[jtbalogh]

Logged In: YES
user_id=1077586

So far, encapsulating reusable code in classes or usercontrols
to get everything out of the form module has been
unsuccessful. The difficulty in simplifying the MidiTest demo
code has, so far, been related to the following limitations.

- Can not easily multicast events with "Dim WithEvents" from
control arrays to classes at designtime and runtime in the
IDE. Handling events in control arrays only at runtime is an
option, but extra code would still be needed anyway and
nothing was saved in terms of simplicity. Embedding the entire
control array into a usercontrol is an option, but is still
complex to implement and introduces other limitations. The
goal is a control array that is available and visible at design
time for convenience, while its code is encapsulated in a class.

- Can not easily share and manage hundreds of data,
functions, and object references between the form and lots
of classes or usercontrols. Worse if using a class hierarchy,
with classes or usercontrols within other classes or
usercontrols. It could be easier if functions are separate from
data like in database applications, but that is still slower in
speed, not as modular and not always possible.

- Usercontrols can resolve limitations that classes can not
handle, but are more complex to implement and introduce
other limitations.

- The extra effort needed to implement these features can
eventually be applied to code in visual basic 6, but would not
easily be backward compatible with the older visual basic 5,
nor forward compatible with the newer .NET or other
compilers.