Would this need to be MDI Forms? 2

[lespaul]

I am re-writing an application I developed (a Jury Management System). This was the first Delphi application and the first "big" application I did. Needless to say the code makes me CRINGE! So, I'm working on version 2, including all the tricks I've found here!

So, I have a process that allows the clerks to update juror information. In the first version a search form opens, the criteria is entered and the information is shown. To see another juror's information, the first Juror Information form is closed and the search form reopens for the next search criteria.

What I'm thinking about doing is allowing multiple Juror Information forms open at the same time. So if the clerk is working on a juror and gets a call about some other juror they can search for the phone call information without closing the juror they are currently working on. Would this be an example of an MDI form? If so, any one know where I can get some good information about MDI forms (how to use them, close them, find open windows, etc.)?

Thanks for any insight!

Leslie

 

[lespaul]

Ok, so after reading a little bit about MDI forms, I don't think that's the way I need to go. Should I just look into creating a new JurorInformation Form for each search? Is that a feasible alternative? Any other suggestions?

Thanks,

Leslie

 

[towerbase]

Leslie

I think that creating a new JurorInformation form for each search is a feasible way to go. It would help the user to have a list of open JurorInformation forms so that they can access and/or close them. This list could be displayed as a menu option - as implemented in many software products such as Microsoft Word.

An alternative would be to show the juror information on tabsheets on a page control. Your users might find this more manageable than having lots of windows all over the place.

If you can, it might be a good idea to prototype different approaches and ask your users which they prefer.

Andrew

 

[lespaul]

So, Andrew, how would I implement your first suggestion, creating a Juror Information form for each search and having the 'Window' menu choice that shows all the open windows? How do I name each "new" Juror Information form?

And I really don't think the users will have "lots" of windows open, but right now they are restricted to having just one.

Thanks for any additional info!

leslie

 

[Punchinello]

I would recommend that you do implement an MDI interface because it is designed for exactly what you described with minimal programming.

I agree that having a bunch of windows open is confusing, but since you said "... I really don't think the users will have "lots" of windows open, but right now they are restricted to having just one.", it doesn't seem as if that is a concern.

You might try these steps to see if an MDI interface is really what you (or your users) want:

1. change the FormStyle property of the main form to "fsMDIForm";
2. set the WindowMenu property of the main form to the main menu item under which you want the open JurorInformation form list to appear;
3. remove your JurorInformation form from the set of auto-created forms; and
4. change code that opens your JurorInformation form to create it first (since it is not auto-created) and make sure that the instance is released when closed.

Good Luck!

 

[lespaul]

except i found that if I use MDI forms then the labels I have on the MainForm won't show. I have several stringgrids with labels on the "Main" form of the application to show the current status of several items. If I change it to MDI, then I won't be able to show the users this information (and it's not optional, that information must be shown on the main form).

Leslie

 

[Punchinello]

If you place these items in a TPanel and set its alignment to top,right,left or bottom, they will show and the MDI form area will be restricted to a smaller area.

 

[lespaul]

Then what about all the other forms that I have, will these automatically only show in the MDIarea? This is the only portion of the project that needs multiple windows. When I think of an MDI, I think of Word. It does one thing, creates documents, and you can create lots of documents at one time. But this program does LOTS of things (here's the description):

- an integrated program that tracks the court’s process of summoning jurors, tracking summoned jurors, generating reminders and notices, generating panels, tracking hours, tracking trials served upon, trial duration and outcomes, reporting payment due information and voucher tracking, and generating required reports.

The only time I need the multiple forms is for the juror information.

Is MDI still a valid option in this situation?

leslie

 

[Punchinello]

If other forms are not defined as MDIChild forms, then they will appear "over" the main form as they probably do now. MDIChild forms, by contrast will appear "within" the client area of the main form. Using the MS Word example, if you open or create a document, it appears in the client area of the main form. But if you select Format|Font from the menu, the font window appears over top of the main form and is not the least bit concerned with the MDI interface.

Your program description seems to include lots of reports. If you provide an integrated on-screen preview, this feature (probably more so than the JurorInformation) represents a common use of the MDI interface.

I don't mean to complicate your decision and maybe if I saw the whole app, I might not go MDI either. I guess if you consider the interface of MS Word and try to see your forms in place of MS Word forms you'll see what parts of your app are suited for MDI and what are not.

HTH, Dave

 

[lespaul]

Ok, so now I've seen the problem with what I'm trying to do, maybe someone can help!

The user selects the menu choice: Juror Information

The JurorSearchInformation form opens and the user can enter a JurorNumber, a Panelid or a SSN to search on. Once a matching juror is found, the Juror Information form opens (mostly DBEdits) showing the query information. Now the user wants to search for a second juror, so I have to run the query again to get the second person's information. How do I create a new query for each form so that the original form still keeps it's information, but the second search gets the new information? Or is there something I'm missing in my thought process. If I close and re-run the query, won't the information be lost from the original form?

Any ideas?

Thanks,
leslie

 

[Punchinello]

There are many ways to skin this cat.

One option is to change the DBEdits on your jurors form to be non-data-aware Edit controls that are populated in code. With this approach, once you populate the form, the query can be closed and/or re-used. However, this approach would require a bunch of additional changes (ie. handling edits to the juror data, handling fields with pick-lists, etc.)

My preferred solution would be to place a Query component directly on the JurorInformation form with a SQL statement that queries the table based on a unique indexed field (aka. primary key) value like "SELECT * FROM JurorTable WHERE JurorNumber = X", assuming that JurorNumber is such a field.

Of course, a) you won't want to create a new instance of the JurorInformation form if the search is unsuccessful; and b) you don't want to limit user searches to this field.

So you would use your JurorSearchInformation form as it currently exists, changing only the code that executes for a successful search. Probably, you open the JurorInformation form and link its datasource to your query so that its controls reflect the query values. Instead, you would create the JurorInformation form and execute its own SELECT statement, adding the JurorNumber from the result of the JurorSearchInformation form's query. Sure, you're executing a query twice, but on a unique, indexed field this will be nearly instant. And when multiple instances of the JurorInformation form are present, each will reflect data from its owned Query and none are dependent on the search form.

Good Luck!

 

[lespaul]

So if I drop the query component on the form instead of in a datamodule then I can use the same query over and over since each instance of the form has it's own query?

Is that what you're saying? I do need to keep the DB controls on the page since the users edit and update the information from there and I don't want to have to write all the code to handle all that!

Thanks!

Leslie

 

[Punchinello]

So if I drop the query component on the form instead of in a datamodule then I can use the same query over and over since each instance of the form has it's own query?

Exactly.

But remember, you'll need 2 query components:
1) the re-usable query that executes the user's search; and
2) the one-time query that executes when the data form is created.

So the code sequence goes like this:
1) user selects Juror Information from the menu and sees the JurorSearchInformation form.
2) user enters search criteria and query #1 is executed.
3) upon successful find, your code creates the JurorInformation form, adds the JurorNumber from query #1 to query #2 and executes it.
4) user interacts with JurorInformation form.

 

[lespaul]

Can you tell me what code I need to do step #3 (creating the JurorInformation form)

Thanks,

Leslie

 

[Punchinello]

Sure. You can use the form create procedure, passing the main form as the Owner parameter:

TJurorInformation.Create(MainForm)

or you can use the application createform procedure:

Application.CreateForm(TJurorInformation, JurorInformation)

When I need the owning form to do stuff on a form it creates, I usually use the with clause like so:

with TJurorInformation.Create(Self) do begin
  try
    // prepare and execute the form's local query
    JurorQuery.SQL.Text := 'SELECT * FROM JurorTable WHERE JurorNumber = ' + YourJurorNumberVariable
    JurorQuery.Execute;
  except
    // release the form if errors occur ...
    Release;
    // ... and report the error
    Raise;
  end;
end;

 

[lespaul]

Worked like a charm! Wish I could give you another star!

leslie

 

[towerbase]

Looks like a good tutorial on MDI, Dave. I'll give you the extra star that Leslie couldn't.

Leslie, am I right in assuming that you now don't want details of the non MDI route? The non MDI route would involve more coding effort on your part.


Andrew

 

[lespaul]

Nope, I got Dave's process to work for me and my users are THRILLED! Now I've just got to figure out placement of the new forms so they are not one on top of the others, any suggestions?

Thanks for checking back in, hope you had a nice weekend!

Les

 

[Punchinello]

Now I've just got to figure out placement of the new forms so they are not one on top of the others...

You can use the child form's (JurorInformation) Position property to make the application automatically cascade multiple MDI children by selecting one of the following three options: poDefault, poDefaultPosOnly, poDefaultSizeOnly.

Since your child form has edit controls placed on it and, therefore, is probably sized the way you want it in design mode, I would recommend poDefaultPosOnly. The other two options will re-size your form in ways you probably don't want.

 

[lespaul]

I'll give that a try this morning! Thanks again!

Leslie