By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,433 Members | 776 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,433 IT Pros & Developers. It's quick & easy.

Problem with Controls in an MDI Application

P: n/a
The problem that I am now having, involves refreshing controls. I have allot of text boxes, several combo boxes and grids. These controls are showing live data from an Oracle database. I have dates in a combo box in my tool bar that are associated with the particular report that the user is opening. When the user picks a different date all of the data in the controls should reload. I originally built an SDI application but needed my tool bar to stay put so I redid it in MDI. In the SDI application when the user chooses a new date in the combo box, an event handler calls my load function and all of the data in the controls in reloaded with new data. In the MDI application, the new data does not show up unless I close and re show the MDI child. This of course makes the application too slow and is unacceptable. Also, I am having another problem with a control. This control is on the parent and is the dates combo box that I mentioned above. If a user clicks new report a dialog with a date time picker pops up and the user is able to select a date for the report and say OK. At this point the new date is to be inserted into the combo box (combobox.Items.Add(string)) as this happens the index of the new item is captured and the combo box is set to the new date. In the MDI application this does not happen. The combo box does not receive the new date. In fact, if I try to get a count of the items in the combo box within this event handler or a separate function, it comes back as zero, even though I can see that there are items in the list. In the SDI application, none of these problems exist. I have tried several different ways to get around this problem, and have shared it with the other developers on my team; we are all stumped. Has anyone ever seen this before? How can I fix it?
Nov 16 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hi John,
"John Tyce" <jt***@chevrontexaco.com> wrote in message news:Oa**************@TK2MSFTNGP15.phx.gbl...
The problem that I am now having, involves refreshing controls. I have allot of text boxes, several combo boxes and grids. These controls are showing live data from an Oracle database. I have dates in a combo box in my tool bar that are associated with the particular report that the user is opening. When the user picks a different date all of the data in the controls should reload. I originally built an SDI application but needed my tool bar to stay put so I redid it in MDI. In the SDI application when the user chooses a new date in the combo box, an event handler calls my load function and all of the data in the controls in reloaded with new data. In the MDI application, the new data does not show up unless I close and re show the MDI child. This of course makes the application too slow and is unacceptable.
It's not clear (to me) how your application interface is structured. SDI and MDI are very different interface styles. MDI implies multiple child forms open at one time. It sounds like the toolbar/combo box is on the MDI parent form. Does the combo box need to update multiple child forms at once...or only the active child form...or maybe you are assuming that only one child form will ever be open?

Basically, you need to make the "Load" method of the MDI child form public. Then, in the event handler of the combo box, you need to iterate through the MdiChildren collection of the MDI parent form and identify the child form(s) that need(s) updating and call the Load method on that (those) form(s).

...
foreach(Form form in this.MdiChildren)
{
MyChildForm myChildForm = form as MyChildForm;

if (myChildForm != null) myChildForm.Load(...);
}
...
Also, I am having another problem with a control. This control is on the parent and is the dates combo box that I mentioned above. If a user clicks new report a dialog with a date time picker pops up and the user is able to select a date for the report and say OK. At this point the new date is to be inserted into the combo box (combobox.Items.Add(string)) as this happens the index of the new item is captured and the combo box is set to the new date. In the MDI application this does not happen. The combo box does not receive the new date. In fact, if I try to get a count of the items in the combo box within this event handler or a separate function, it comes back as zero, even though I can see that there are items in the list. In the SDI application, none of these problems exist. I have tried several different ways to get around this problem, and have shared it with the other developers on my team; we are all stumped. Has anyone ever seen this before? How can I fix it?
Things rarely "just don't work". Are you certain that you are always dealing with the same combo box? Is it possible that the combo box is getting cleared before you retrieve items from it. Can you post the routines that add and retrieve items from the combo box?

Regards,
Daniel

P.S. It usually is a good idea to post messages to newsgroups in "plain text" rather than html.
Nov 16 '05 #2

P: n/a
Yeah, there only one child. I made the application and MDI because there are allot of controls on the form and the user does not want tabs. Because of this the user has to scroll up/down and back/forth in order to see and access all of the controls. As an SDI application, if the user was in the bottom right corner of the application and wanted to save a change, they had to scroll back up and over to hit the save button. I needed to tool bar to always be visible, so I put the save,new report, and print buttons on a tool bar in on the parent form. Now they can scroll around and the toolbar stays put. There are no other children and the load function is public. What I would really like is a tool bar that would float at the top as it does now, but on an SDI application (a floating tool bar that stays put).

--
JOHN TYCE
"Daniel Pratt" <ko******************@hotmail.com> wrote in message news:eB**************@tk2msftngp13.phx.gbl...
Hi John,
"John Tyce" <jt***@chevrontexaco.com> wrote in message news:Oa**************@TK2MSFTNGP15.phx.gbl...
The problem that I am now having, involves refreshing controls. I have allot of text boxes, several combo boxes and grids. These controls are showing live data from an Oracle database. I have dates in a combo box in my tool bar that are associated with the particular report that the user is opening. When the user picks a different date all of the data in the controls should reload. I originally built an SDI application but needed my tool bar to stay put so I redid it in MDI. In the SDI application when the user chooses a new date in the combo box, an event handler calls my load function and all of the data in the controls in reloaded with new data. In the MDI application, the new data does not show up unless I close and re show the MDI child. This of course makes the application too slow and is unacceptable.
It's not clear (to me) how your application interface is structured. SDI and MDI are very different interface styles. MDI implies multiple child forms open at one time. It sounds like the toolbar/combo box is on the MDI parent form. Does the combo box need to update multiple child forms at once...or only the active child form...or maybe you are assuming that only one child form will ever be open?

Basically, you need to make the "Load" method of the MDI child form public. Then, in the event handler of the combo box, you need to iterate through the MdiChildren collection of the MDI parent form and identify the child form(s) that need(s) updating and call the Load method on that (those) form(s).

...
foreach(Form form in this.MdiChildren)
{
MyChildForm myChildForm = form as MyChildForm;

if (myChildForm != null) myChildForm.Load(...);
}
...
Also, I am having another problem with a control. This control is on the parent and is the dates combo box that I mentioned above. If a user clicks new report a dialog with a date time picker pops up and the user is able to select a date for the report and say OK. At this point the new date is to be inserted into the combo box (combobox.Items.Add(string)) as this happens the index of the new item is captured and the combo box is set to the new date. In the MDI application this does not happen. The combo box does not receive the new date. In fact, if I try to get a count of the items in the combo box within this event handler or a separate function, it comes back as zero, even though I can see that there are items in the list. In the SDI application, none of these problems exist. I have tried several different ways to get around this problem, and have shared it with the other developers on my team; we are all stumped. Has anyone ever seen this before? How can I fix it?
Things rarely "just don't work". Are you certain that you are always dealing with the same combo box? Is it possible that the combo box is getting cleared before you retrieve items from it. Can you post the routines that add and retrieve items from the combo box?

Regards,
Daniel

P.S. It usually is a good idea to post messages to newsgroups in "plain text" rather than html.
Nov 16 '05 #3

P: n/a
Hi John,
"John Tyce" <jt***@chevrontexaco.com> wrote in message news:eS**************@TK2MSFTNGP15.phx.gbl...
Yeah, there only one child. I made the application and MDI because there are allot of controls on the form and the user does not want tabs. Because of this the user has to scroll up/down and back/forth in order to see and access all of the controls. As an SDI application, if the user was in the bottom right corner of the application and wanted to save a change, they had to scroll back up and over to hit the save button. I needed to tool bar to always be visible, so I put the save,new report, and print buttons on a tool bar in on the parent form. Now they can scroll around and the toolbar stays put. There are no other children and the load function is public. What I would really like is a tool bar that would float at the top as it does now, but on an SDI application (a floating tool bar that stays put).
Add a new form to the project. Add a toolbar to the form (it should dock to the top automatically). Add a panel to the form. Set the Dock property of the panel to "Fill" and set the AutoScroll property of the panel to "True". Put the controls within the panel.

Regards,
Daniel
Nov 16 '05 #4

P: n/a
That is exactly what I wanted. Thanks Daniel.

--
JOHN TYCE
"Daniel Pratt" <ko******************@hotmail.com> wrote in message news:OZ**************@TK2MSFTNGP10.phx.gbl...
Hi John,
"John Tyce" <jt***@chevrontexaco.com> wrote in message news:eS**************@TK2MSFTNGP15.phx.gbl...
Yeah, there only one child. I made the application and MDI because there are allot of controls on the form and the user does not want tabs. Because of this the user has to scroll up/down and back/forth in order to see and access all of the controls. As an SDI application, if the user was in the bottom right corner of the application and wanted to save a change, they had to scroll back up and over to hit the save button. I needed to tool bar to always be visible, so I put the save,new report, and print buttons on a tool bar in on the parent form. Now they can scroll around and the toolbar stays put. There are no other children and the load function is public. What I would really like is a tool bar that would float at the top as it does now, but on an SDI application (a floating tool bar that stays put).
Add a new form to the project. Add a toolbar to the form (it should dock to the top automatically). Add a panel to the form. Set the Dock property of the panel to "Fill" and set the AutoScroll property of the panel to "True". Put the controls within the panel.

Regards,
Daniel
Nov 16 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.