Re: [PATCH] [WIP] fdo#45747 - [EasyHack] remove the limitation to 3 sort entries in calc, part 2

Servus Markus,

Just an update on what I've been doing on this.

On Sun, Apr 29, 2012 at 4:37 PM, Markus Mohrhard
<markus.mohrhard@googlemail.com> wrote:
> > So far so good I think, then comes the ugly bits:
> >
> > 1.) Obviously I'm using the wrong widget class for ScSortKeyDlg since
> > each dialog opens in a separate window and are not embedded in the
> > main dialog.
> > Which widget should I use here?
>
> Yeap. You need to derive from a Control and not from a Window. A good
> example for such a concept is SfxDocumentInfoDialog with the
> CustomProperties* classes. They already implement something similar
> and we can copy most of the ideas from there.

I've solved this part like this:
Tab page class <-> Controller class <-> Window class <-> Struct
{FixedLine, ListBox, RadioBtnUp, RadiobtnDown }

Basically copying the set-up of SfxDocumentInfoDialog, I've tested
this part and it works like a charm!

> > 2.)  Related to the above is the question about how to position the
> > sort key dialogs relative to each other.
>
> We need to write the code that calculates the position of sort
> entries. We will position them inside another control so the
> positioning has to be done only relative to the control.

I've implemented the scroll handler but I haven't tested it yet.

> > 3.)  The Listbox handler. The handler is used to enable/disable the
> > widigets of the subsequent sort key(s). Now that each sort key is an
> > instance of its own I'm not sure how to get "the signal across" form
> > one instance to the other. Can I catch this event in the control
> > class?
>
> There are at least two solutions to this. First one is to give the
> sort entry a reference to the class that needs to know about it or
> implement the handler already in that class.

This part was simple, It is basically the same handler as before, only
slightly modifed. For now i put this implementation in the Window
class, but I'm thinking of moving it back were it was before i.e in
the tabpage class. I've tested this as it is now and it works!

Overall I'm still contemplating a bit where to put the code containing
all the the logic behind the dialog. My second attempt here was to
move everything from the tab page class to the window class, but I
this turned out to create more messy code than I had anticipated.

So now I'm opting to keep much of the code intact in the tab page
class. I need to re-wind a bit here, before I have a working patch to
submit.

/Albert