🚀 go-pugleaf

"Rodolfo Frino" <rodolfowrvxg527u7qfrino@yahoo.com.jki> wrote in message
news:3fa1f406@newsgroups.borland.com...
> There is an easier way if you clear the options ;)

What do the Options have to do with anything?  The option settings that are
enabled by default are ofHideReadOnly and ofEnableSizing, neither of which
effect the dialog's ability to be moved.

>     OpenDialog1->Options.Clear();

You cannot clear the Options like that.  You are modifying a temporary
value, not the original property value.  Just like with other Set
operations, you need to use the '=' assignment operation instead, ie:

    OpenDialog1->Options =  TOpenOptions();

> void __fastcall TForm1::OpenDialog1Show(TObject *Sender)
> {
>       H = FindWindow(NULL, DlgTitle.c_str());
>       MoveWindow(H, 0, 0, 0, 0, false);
> }

I have already determined that you cannot move the dialog from the OnShow
event. That is why my earlier example had to delay the movement.  OnShow is
triggered during the handling of the WM_INITDIALOG message, however
TOpenDialog internally repositions the dialog during the handling of the
CDN_INITDONE notification later on, thus cancelling out any movements you do
in the OnShow event.

> void __fastcall TForm1::OpenDialog1SelectionChange(TObject *Sender)
> {
>     MoveWindow(H, 0, 0, 800, 300, true);
> }

I guess you missed the point  of my earlier example - the OnSelectionChange
event is triggered well after the dialog has become visible, so the user
sees the dialog appear in the middle of the screen and then move to the
coordinates seconds later.  Which even you said earlier was an ugly effect
:-p  Thus my use of disabling the dekstop's ability to update the screen
while the dialog is being moved, so the user won't see it happen.


Gambit