On Tue, 05 Jun 2007 23:26:01 -0700, <Petedwrote:
[...]
if this is all done in the MDI parent form, how can i get all the
childforms throughout the app to access the kvm1, kvm2, kvm3 instances
It just depends on where you want to put them. To some extent it seems to
me it depends on what part of your code is responsible for ensuring that
the Device instances exist. If the main parent form does so, then I would
think the main parent form class would be a natural place to keep them.
The MDI children would then just use their parent to access the Device
instances.
I think Moty's suggestion is a good one too. For example, make a public
static class within the application's namespace that handles maintenance
of the Device instances. The class itself would be accessible by any
other class in the assembly (or any that references it for that matter,
assuming you do make it public...make it internal if you don't want
that). So each MDI child class instance would just reference the static
class to get the Device instances.
As an example of the latter:
public static DevicesManager
{
public class Device
{
// this class doesn't have to be contained by the
DevicesManager,
// but maybe it makes sense to do so, in order to keep
everything
// together
}
private List<Device_rgdevice = new List<Device>();
public Device DeviceFromIndex(int i)
{
return _rgdevice[i];
}
public void AddDevice(Serialport sp)
{
Device kvm = new Device();
kvm.sp = sp;
_rgdevice.Add(kvm);
}
}
Then in code in the MDI child class, you'd get a device like this:
Device kvm = DevicesManager.DeviceFromIndex(1);
The above is just a vague bit of hand-waving to try to illustrate why a
static class is useful here. Obviously, you can write your device
initialization and access stuff however you actually think makes sense.
The main thing is just that if you have such a static class, then other
classes can call it directly to get stuff from it or to have it do things.
Pete
