How to go further with app

[dpaterso]

I am writing this message because I just know that I am going to run into a problem later on (soon) down the line with my app.

I need things to work in this order:

Main Window (MDI)
|
Child Window (MDIChild) with TWBrowse (displays current records)
|
Select TWBrowse Record by Double Clicking (or something)
|
Dialog with Edit Screen Opens
|
From Dialog need another Window to open with a TWBrowse
|
Must be able to add, edit, and / or view the above TWBrowse

My problem is this:

So far everything is working perfectly up until 'Dialog with Edit Screen Opens'.

BUT

I know (from past experience) that when I open the new Window from the Dialog, because I am working in an MDI environment, once that Window is open I know that I can click out of that Window at any point, the focus changes to where I have clicked, and that Window remains open in the background and I cannot have this happen.

In other words, in an MDI environment, how do you open a sort of 'Modal Window' (just like a Modal Dialog) i.e. once this particular Window is open how do you stop a user from clicking anywhere else but in that Window until that Window is explicitly closed by the user (bearing in mind that you may have, at this point, about two or three other open Windows prior to even opening this Window).

I seem to remember something James wrote about a long time ago about opening a Dialog as a Window or making a Window appear as if it were a Dialog or something like that?

This would solve my problem (I think) because if a Window was opened and it behaved as if it were Modal Dialog then you would not be able to click out of it without closing it first.

I did post something like this a short while ago and received and answer from Antonio but I did try the solution and this did not work for me i.e. it would have worked if I was working in my first MDIChild Window by disabling my main MDI Window but I have at least one other MDIChild Window open at this point so I cannot use the oWndMain:Disable( ) and oWndChild:Disable( ) because at this point I already have another oWndChild open i.e. the isable( ) only worked on the previous level of open Window and not if there were more than one MDIChild Window open.

Phew, that was some explanation!

Help!

Dale.

[Enrico Maria Giordano]

Can't you just use a modal dialog?

EMG

[James Bott]

Dale,

My first advice would be to avoid MDI. Note that Microsoft is not using MDI anymore either.

There is way too much user required manipulation of the windows in a MDI application. They spend half their time messing with the Windows rather than getting their work done. An Outlook type SDI (single document interface) is much more efficient.

But to solve your problem, as Enrico said, use a dialog as a container for the second browse.

James

[dpaterso]

Hello James,

To be honest - YOURS was the comment that I was waiting for - the whole day - in anticipation!

I know that you have told me this before but there is a practical reason for me using MDI.

As you know - it is (finally) a rewrite of our old Fleet Management System and the idea is that there are certain tables of information that a Fleet Manager, for example, would probably like to have open at one time on his screen so that 'at the touch of a button' or 'at a glance' (already working on my sales pitch) he has the information right there.

I still really need advice on one portion of the app though (as detailed at the start of this message thread) - and it is probably the 'guts' of the system - and it is worrying me terribly - even before I get to it!

Maybe - if you (and Enrico) have the time I could post a download link to what I have so far (I'm not posting the code as I just know what you will have to say about it) and you could maybe give me some ideas. I mean I know how I want it to work but I can't seem to fathom practically how I am going to do it!!!

Regards,

Dale.

[James Bott]

Dale,

I know that you have told me this before but there is a practical reason for me using MDI.

As you know - it is (finally) a rewrite of our old Fleet Management System and the idea is that there are certain tables of information that a Fleet Manager, for example, would probably like to have open at one time on his screen so that 'at the touch of a button' or 'at a glance' (already working on my sales pitch) he has the information right there.

Of course, you must provide the user the information that they need, but I am sure you can do it in SDI. SDI doesn't mean you can only show one table at a time. Take another look at Outlook. Can you send me a screenshot of what you think you must do with MDI?

Maybe - if you (and Enrico) have the time I could post a download link to what I have so far...

Post it.

James

[dpaterso]

Thanks,

Here it is:

http://www.fleetfocus.net/software/images/fwngtest.zip

Have a look at it.

Half of the 'Edit' menu options work so far - open them all up and then tile them and see how good it looks

The point is that it would be nice to have, say the 'Suppliers' open on the left for quick access to their phone numbers, and possibly the 'Vehicles' open on the right hand side for quick access (ironically neither of these options are working yet but you get the idea).

Please have a look (while I go and have dinner) and I will gracefully accept your comments shortly and explain why I need these additional dialogs and windows open as I get to the 'nitty gritty' of the system.

And by the way - don't go creating 5 000 000 records and run it on a network - I have not removed my nFileCRC( )'s yet!!!

Regards,

Dale.

[James Bott]

Dale,

The point is that it would be nice to have, say the 'Suppliers' open on the left for quick access to their phone numbers, and possibly the 'Vehicles' open on the right hand side for quick access (ironically neither of these options are working yet but you get the idea).

As I said, you can do this with an SDI app. Take a look at \samples\testspl1-testspl6. And do a Google for Outlook images.

James

[dpaterso]

OK - well maybe (you really are a man of few words)!

But MDI or SDI it still does not solve my 'how to' have a dialog box with Gets, and Browses with inline input (or something).

But let me think about the logic of what I am trying to do and when I get there maybe you can be of help.

Regards,

Dale.

[E. Bartzokas]

Dale,

CUSTOMER.PRG that comes with FWH might help you...

Regards
Evans

[José Luis Sánchez]

You can use my FSDI class. Have a look at:
http://www.avemundi.com/archivos/000148.html
http://www.avemundi.com/archivos/000048.html

Regards,

[James Bott]

"dpaterso"]OK - well maybe (you really are a man of few words)!

Sorry, I needed some sleep.

But MDI or SDI it still does not solve my 'how to' have a dialog box with Gets, and Browses with inline input (or something).

Well, I am not sure exactly what your 'how to' is. I use a browse in one pane of the SDI interface and the user double-clicks on a record to get an edit dialog. I don't know what you mean by "inline input."

But let me think about the logic of what I am trying to do and when I get there maybe you can be of help.

I highly recommend getting a copy of Alan Cooper's book "About Face 2.0, The Essentials of Interaction Design." This will help a lot.

Regards,
James

[dpaterso]

Good Morning,

I don't know what you mean by "inline input."

By 'inline input' I mean entering data directly into the cells of a TWBrowse (FWH ONLY) i.e. Get first cell data, validate etc., move on to next, validate etc., and so on and so forth.

I did start testing with this but have not gotten down to it seriously (it kept coming up with array bounding errors and I know I have to do a lot of work to get my head around the input validations).

Regards,

Dale.

[James Bott]

Dale,

By 'inline input' I mean entering data directly into the cells of a TWBrowse (FWH ONLY) i.e. Get first cell data, validate etc., move on to next, validate etc., and so on and so forth.

I have only used that in rare instances. Usually, there are too many fields to display on the screen without scrolling horizontally. If the user has to to that, then you making them work harder than just using a dialog. Dialogs are built for data entry and validation and you have room for prompts, groups, folders, etc. So, I recommend using dialogs most of the time.

And, you probably don't want to get me started on validation...

James

[dpaterso]

Hello,

Actually - I wouldn't mind at all.

I'm actually not really very good at 'thinking out of the box' so your opinions count for much.

As far as the 'inline editing' is concerned there are very many extremely popular accounting packages here (one in particular has market share) and they all use this sort of 'Excel' style input.

The most popular one of them all actually displays the entire document on the screen EXACTLY as it will print - company logo, headings, colors, lines, EVERYTHING - and all the user has to do is enter the documents details. Kind of WYSIWYG mode - and this has definitely been a strong demo or selling point of the system i.e. it looks impressive although because of the Windows Printing System actually getting on the paper what you saw on the screen can be a nightmare with all the different printers around.

Whether or not this is really the way to go I just do not know (just from a design perspective).

Me personally - dot matrix printing, old line by line data input, z.zz..zzz.. Ouch! Stop Dreaming!

Have to move on, have to!

Dale.

[James Bott]

Dale,

I will consider writing something up on validation. You can get a lot of this from Alan Cooper's book.

As exepected, Exel style will be liked by accountants, because they are used to it. That doesn't make it the best method of collecting data.

The basic concepts of good interface design are that less is more, and we have to help the user reach their goals. No matter how cool the interface is, less of it would be better. I. E. the less the user has to do to reach their goal the better. Things like manipulating windows are mere overhead and don't get the user any closer to their goals.

We also have to be careful about assuming what the user's goals are. Many user's goals are things like, don't look stupid, have some fun, work less, etc. They may not be the business goals that you might think they would be. The trick is to accomplish both.

WYSIWYG screens may be flashy but they also may present more overhead work for the user. For some unknown reason, computer monitors are in landscape mode and paper is in portrait. Thus, to replicate paper on screen you must force the user to do a lot of scrolling--more unnecessary overhead.

Ideally, we should be coaxing our users to get away from using paper anyway. I know it is not an easy road.

Did you read the article titled "Magic and Software Design," that I posted a link to a week or so ago? It is a good read and will help get you thinking outside the box.

James