Re: EditGrid options

Dave Page wrote:

>It's rumoured that Andreas Pflug once said:
>
>
>>I didn't spent too much time thinking about how it should look, just 5
>>seconds, but a modal dialog is the 0.1 second solution...
>>
>>
>>
>What is your problem with modal dialogues? They are used in all manner of
>applications for setting options such as these. Not using modal dialogues
>for things that are quick open/modify/close options can lead to problems
>for the inexperienced user when they accidently leave two or three open
>and then lose track of the parents. iirc, it was for this exact reason
>that you made the add column dialogue modal (might not have been that one,
>but you know what I mean).
>
>
I'm against popup dialogs at all! Certainly, in this case if used at
all, it must be modal.

>Few can argue that Microsoft don't produce some of the best user
>interfaces around in their mainstream products, yet they have no problem
>using modal dialogues in situations like this.>
>
>

The stacking of modal dialogs that MS performs is one of their worst ui
sins!

The options dialog would make sense if it would modify the behaviour of
the EditGrid itself (persistent options like bg color, ...), but not for
the data.

>>I mean that applied filter (as soon as it is implemented)
>>
>>
>>
>It is now.
>
>
>>and sorting
>>should be visible, not hidden in that options dialog. This is
>>especially senseful if you insert something out of the scope of the
>>filter, and do a refresh ("hell, where did my data go!")
>>
>>
>>
>That's an easy fix. For example, Outlook puts a 'Filter Applied' label at
>the top of the listbox.>
>
>
Could be, I'm not sure if we can have a 3rd line in the header control.

>>No, thats *not* what I'm talking about.
>>I'll be using EditGrid normally for small tables, thus I need autoquery
>> 90% of the time (no filter, no sort). The other 10 % might be very
>>long running, thus I'd like the option to enter the grid, having the
>>chance to filter before the query executes.
>>This would look&feel very dirty if filtering is done using a modal
>>dialog....
>>
>>
>>
>I think it makes little difference how the sort/filter is implemented to
>this (completely seperate) problem.
>
Not quite. Popup dialog wouldn't be a good idea.

> What you are asking for is a second
>view data menu option that doesn't auto query, however that would be ugly
>as well. As it stands now, you are no worse off than in 1.0.0. With an
>auto query toggle button, those that know they are working on large data
>sets can turn it off in advance,
>
How that? In global options? That's nasty. Second menu is easier to use.

>or on first use during the task.
>Any other way will either look like a kludge, or inconvenience to those
>who want to actually view data when the select the option, not be asked if
>they want to see the data as well.>
>
>
>>Notebook was just the first thought, propose something better.
>>Some expandable/collapsable options pane would be possible.
>>
>>
>>
>That's certainly more palatable than a notebook, but I'm still not
>convinced it's the best way.>
>
>
So be positive, and make proposals.

>>How about abbrevations if it really doesn't fit? This looks *ugly*!
>>
>>
>>
>OK, now I get it. Clearly you had too much beer last night :-). How can
>you possibly say that abbreviated text will look better than buttons that
>are 25% or so wider than normal, particularly when those button are
>uniform sized in their own group, fit into the space they are positioned
>in properly, and are visually seperate from any other buttons of different
>size?
>
>
So get rid of that buttons.

>If you are going to try to enforce a style guide without consultation with
>the rest of us first, at least make sure that you specify objects big
>enough for perfectly reasonable captions.>
>
>
There's some aesthetical limit on button sizes. IMHO this limit is
nearly reached. Standard size for MS buttons is (46,15d), btw.

>>Yep, you already found it. Still, I wonder why you don't use the
>>existing methods. Creating the lb columns is a one-liner.
>>
>>
>>
>2 lines of simplified code is more efficient than 1 line calling an
>overcomplicated (for my purpose) function. Not that it matters from a
>performance pov, but it is more easilt understandable.>
>
>
I'm counting 5 lines... CreateListColumns takes two strings as
left/right header, and the size of the left header in DlgUnits, do you
need less?

>>Regarding the ctlSQLBox xrc attachment: IMHO it's saver to implement a
>>custom xrc handler for this; I'll check it in soon.
>>
>>
>>
>A good idea. How would xrced cope though? As far as I'm aware it's still
>the best (free) xrc editor, and I'd hate to have to lose use of it for the
>sake of a couple of lines of code.
>
>
We won't get around it anyway (wxCalendarBox on the way). The control
type has to be changed in a text editor. After that, id/pos/size/style
can be edited in XRCed as usual.

Regards,
Andreas