Preventing MDI child form from losing focus
-
Hi all, I have an MDI container app with several MDI children forms that can be open at any one time. I had a problem, which I think I've solved fairly elegantly, but which introduced a new problem. Maybe someone here can make suggestions. The original problem: Changes on one MDI child form could affect the contents of another MDI child form. So what I did was to have each MDI form implement an interface with a
RefreshForm()function. Each MDI child form will the override this function in which the data on the form is repopulated. Whenever a form submits changes to the data source (ie. changes that might affect the contents of any other form, it calls a function which iterates through all the open MDI children forms on the app and calls theRefreshForm()function for each. The new problem: The new problem is that, if a user was still busy editing data onForm A, switches toForm Bto make changes there without submitting the changes he was busy making toForm Aand then submitting the changes he made toForm B, you can already guess what happens.Form Agets repopulated and all unsaved changes are lost. No way around this, at least not that I can think of. So I was thinking I can override theDeactivateevent handler for these forms and warn the user that changes have been made and that these may be lost. I'd like, however, to provide an "OK" and "Cancel" button on theMessageBox, so that the "Cancel" button will take the user right back to the form he was busy editing. But how? If, in theDeactivateevent handler I show aMessageBoxand callFormA.Focus()if the user clicks "Cancel", for some reason the newly selected form still has focus as opposed toForm A. Any advice? -
Hi all, I have an MDI container app with several MDI children forms that can be open at any one time. I had a problem, which I think I've solved fairly elegantly, but which introduced a new problem. Maybe someone here can make suggestions. The original problem: Changes on one MDI child form could affect the contents of another MDI child form. So what I did was to have each MDI form implement an interface with a
RefreshForm()function. Each MDI child form will the override this function in which the data on the form is repopulated. Whenever a form submits changes to the data source (ie. changes that might affect the contents of any other form, it calls a function which iterates through all the open MDI children forms on the app and calls theRefreshForm()function for each. The new problem: The new problem is that, if a user was still busy editing data onForm A, switches toForm Bto make changes there without submitting the changes he was busy making toForm Aand then submitting the changes he made toForm B, you can already guess what happens.Form Agets repopulated and all unsaved changes are lost. No way around this, at least not that I can think of. So I was thinking I can override theDeactivateevent handler for these forms and warn the user that changes have been made and that these may be lost. I'd like, however, to provide an "OK" and "Cancel" button on theMessageBox, so that the "Cancel" button will take the user right back to the form he was busy editing. But how? If, in theDeactivateevent handler I show aMessageBoxand callFormA.Focus()if the user clicks "Cancel", for some reason the newly selected form still has focus as opposed toForm A. Any advice?I do believe you are finding out why MDI is not a popular format! I would add an IsEditing flag to the MDI form and refuse to update that form if it is edit mode! Sooner or later managing all the different states and interactions of a complex MDI app will cause it to crawl up it's own bum and dissapear.
Never underestimate the power of human stupidity RAH
-
I do believe you are finding out why MDI is not a popular format! I would add an IsEditing flag to the MDI form and refuse to update that form if it is edit mode! Sooner or later managing all the different states and interactions of a complex MDI app will cause it to crawl up it's own bum and dissapear.
Never underestimate the power of human stupidity RAH
Well said that man. Maintaining an MDI App of any size is excruciating.
-
I do believe you are finding out why MDI is not a popular format! I would add an IsEditing flag to the MDI form and refuse to update that form if it is edit mode! Sooner or later managing all the different states and interactions of a complex MDI app will cause it to crawl up it's own bum and dissapear.
Never underestimate the power of human stupidity RAH
Thanks, not a bad suggestion. I think I'll do that, and also check whether any of the form's data in the data source has changed and if so, display a big red warning on the form that the data has changed and this form cannot be saved anymore - or something like that. I'm surprised to hear you saying that MDI is not a popular format. What would be a popular format then for something like say a CRM applications? Say for instance, you're looking at the details of a customer and then, without having to close that customer and later opening it again, you want to see a list of orders that customer has placed. And then, without having to close that list of orders and later opening it again, you want to see the shipping details for a particular order. MDI just seemed to me like the perfect format for this kind of application (and of course it brings with it all sorts of extra challenges). But I'd be interested to know what a more appropriate format would be.
-
Thanks, not a bad suggestion. I think I'll do that, and also check whether any of the form's data in the data source has changed and if so, display a big red warning on the form that the data has changed and this form cannot be saved anymore - or something like that. I'm surprised to hear you saying that MDI is not a popular format. What would be a popular format then for something like say a CRM applications? Say for instance, you're looking at the details of a customer and then, without having to close that customer and later opening it again, you want to see a list of orders that customer has placed. And then, without having to close that list of orders and later opening it again, you want to see the shipping details for a particular order. MDI just seemed to me like the perfect format for this kind of application (and of course it brings with it all sorts of extra challenges). But I'd be interested to know what a more appropriate format would be.
It's not that MDI does not do the job, it is excellent for what you describe, however the management of MDI can be extremely challenging. In 20+ years of windows development I have only worked on 1 MDI app and have resisted the temptation ever since. I think MS had a number of MDI apps in the late 90s and moved back to SDI, this also strongly influenced the SDI trend. I am more restrictive and only allow modal dialogs, I often get the complaint that the user wants additional dialogs open at the same time, this I will sometimes do but they are only allowed to work 1 dialog/window at a time.
Never underestimate the power of human stupidity RAH
-
It's not that MDI does not do the job, it is excellent for what you describe, however the management of MDI can be extremely challenging. In 20+ years of windows development I have only worked on 1 MDI app and have resisted the temptation ever since. I think MS had a number of MDI apps in the late 90s and moved back to SDI, this also strongly influenced the SDI trend. I am more restrictive and only allow modal dialogs, I often get the complaint that the user wants additional dialogs open at the same time, this I will sometimes do but they are only allowed to work 1 dialog/window at a time.
Never underestimate the power of human stupidity RAH
Thanks, I'll keep that in mind for future projects. Who knows, maybe this is is that one MDI app that I will have developed after which I will resist the temptation :) Come to think of it, I have actually developed a MDI app before and it was bad. I'd have to be honest though that I don't really agree with the argument that "you stay away from MDI because it's hard to implement", I'd be much more susceptible to the argument "you stay away from MDI because the user finds it confusing or difficult" and I'm not really sure if that is the case. Especially if you say that you often get the complaint that users want additional dialogs open at the same time. Isn't that a bit like a car manufacturer saying "we don't have cruise control on our vehicles because it is difficult to implement"? If that is what the user want then that is what the developer needs to do, whether it's easy or not. Imagine Microsoft Excel telling you, no sorry you can only work on one workbook at a time:confused: So, while Excel these days provide you with an option to view all open work books as separate instances of Excel or as different SDI children of a larger MDI application, I consider both to be some type of MDI - viz. multiple documents are open at the same time, all of which can be edited at the same time and any of which may or may not affect data on any of the other.
-
Thanks, I'll keep that in mind for future projects. Who knows, maybe this is is that one MDI app that I will have developed after which I will resist the temptation :) Come to think of it, I have actually developed a MDI app before and it was bad. I'd have to be honest though that I don't really agree with the argument that "you stay away from MDI because it's hard to implement", I'd be much more susceptible to the argument "you stay away from MDI because the user finds it confusing or difficult" and I'm not really sure if that is the case. Especially if you say that you often get the complaint that users want additional dialogs open at the same time. Isn't that a bit like a car manufacturer saying "we don't have cruise control on our vehicles because it is difficult to implement"? If that is what the user want then that is what the developer needs to do, whether it's easy or not. Imagine Microsoft Excel telling you, no sorry you can only work on one workbook at a time:confused: So, while Excel these days provide you with an option to view all open work books as separate instances of Excel or as different SDI children of a larger MDI application, I consider both to be some type of MDI - viz. multiple documents are open at the same time, all of which can be edited at the same time and any of which may or may not affect data on any of the other.
I don't stay away from MDI just b/c they are difficult to manage, and I don't dissallow my users from seeing multiple windows of information. I don't use MDI b/c I think SDI is a better solution, that solution is made up of many aspects, among them usability, time to deliver and ease of support. Support is the biggest cost of any applcation, MDI complicates support - dramtically, especially if the IP for the app is lost when the developer moves on (I'm a contractor to corporates) You also cannot let users run riot with requirements, as a senior architect part of my job is to reign in some of the more fanciful requests from the users. I still have an outstanding requirement for a Minority Report UI (based on Kinect maybe).
Never underestimate the power of human stupidity RAH
-
I don't stay away from MDI just b/c they are difficult to manage, and I don't dissallow my users from seeing multiple windows of information. I don't use MDI b/c I think SDI is a better solution, that solution is made up of many aspects, among them usability, time to deliver and ease of support. Support is the biggest cost of any applcation, MDI complicates support - dramtically, especially if the IP for the app is lost when the developer moves on (I'm a contractor to corporates) You also cannot let users run riot with requirements, as a senior architect part of my job is to reign in some of the more fanciful requests from the users. I still have an outstanding requirement for a Minority Report UI (based on Kinect maybe).
Never underestimate the power of human stupidity RAH