How do I return to the 'Constructor'??

[Ian Branch 128]

Hi Team,

I have the following constructor:

...
...
private
    procedure LoadFilter;
  public
    wwSaveFilter1: TwwSaveFilter;
    constructor Create(AOwner: TComponent); override; // called before "FormCreate()"
  end;

The code is this:

constructor TChangesLogForm.Create(AOwner: TComponent); // called before "FormCreate()"
begin
  inherited;
  //
  var lCloseForm := False;
  //
  case JSDialog1.Execute of
    100:
      begin
        ChangesLog.TableName := 'ChangesLog';
        iTable := 100;
      end;
    200:
      begin
        //
        BePatientWarningArchive;
        //
        ChangesLog.DatabaseName := 'DBiArchive';
        ChangesLog.TableName := 'AChangesLog';
        iTable := 200;
      end;
    300:
      begin
        //
        BePatientWarningBoth;
        //
        ChangesLog.TableName := 'vAllChangesLog';
        iTable := 300;
      end;
    400: lCloseForm := True;
    //
  end;
  //
  if lCloseForm then Abort;
  //
end;

JSDialog1 is a LMD Dialog.

Based on this the indicated table is opened.

ATT when the User is done he has to close the form and reopen it to look at a different table.

How can I return to this input dialog when the User is finished with that Table?

The idea is that the User could then select another Table or Exit/Close the form.

 

Regards & TIA,

Ian

[Remy Lebeau 1436]

To answer your question - you can't "return to the constructor" once it has exited. You would have to destroy the Form and recreate it.

 

Maybe put the 'case' block inside a loop, and then exit the loop when you are done looking at tables? Hard to say since you did not explain what TChangesLogForm is actually doing and what exactly its relationship to JSDialog1 is. 

 

That being said, why is this dialog code in the Form's constructor? This does not look like good UI class design. This kind of logic should probably not be in the Form's constructor, but rather should be invoked in the calling code before the Form is created to begin with. Again, hard to say for sure without knowing more about your design. 

Edited August 16 by Remy Lebeau

[Ian Branch 128]

Hi Remy,

There is only the one form.

[Cristian Peța 107]

1 hour ago, Ian Branch said:

There is only the one form.

If you create only one form and want to keep it to change the table the I ask myself as Remy asked: why is that code in the constructor?

Also calling Abort into the constructor will destroy the form.

Edited August 16 by Cristian Peța

[Cristian Peța 107]

After you created the form and want to have only one form you can not return to the code into the constructor without creating an other form.

[Remy Lebeau 1436]

6 hours ago, Ian Branch said:

There is only the one form.

Then I'm even more confused about the code you showed earlier. Please explain exactly what this one Form is actually doing, what it looks like, and what you are trying to accomplish with it. Also, what the JSDialog is and what it is doing in relation to this Form. There is just too many unknowns to adequately help you.

[Pat Foley 52]

5 hours ago, Cristian Peța said:

Also calling Abort into the constructor will destroy the form.

How about         

procedure TChangeForm.dostuff(inDBName, inDBTable, inTable: Variant)
begin
if not assigned(Changeform)  then Changeform := Tchangeform.create(Application); 
//
hookup up the incoming
//

end;

 

[Ian Branch 128]

Hi Guys,

Thank you for your inputs.  Appreciated.

The methodology was developed for a specific purpose, to determine the User's choice before the form was constructed/shown.

I use it in multiple Apps.  Some where there is only one form, others where the form is called from a menu.

It does exactly what I wanted/needed.

The idea of returning to the Dialog was just a whim I had to make things a little simpler for the User.

FYI:  The Dialog looks roughly like this, depending on the App:

I have scrapped the 'whim'.

 

Regards,

Ian

Edited August 16 by Ian Branch

[David Heffernan 2353]

8 hours ago, Ian Branch said:

The methodology was developed for a specific purpose, to determine the User's choice before the form was constructed/shown.

You very likely still shouldn't be showing user dialogs in a constructor. The fact that you made this design choice to meet a requirement does not mean that it was the right design choice. 

[Pat Foley 52]

On 8/15/2024 at 5:58 PM, Ian Branch said:

BePatientWarningBoth;

How about a second machine for the user.   They can view old work flows to gain insight on the work flows they are working on presently.  This second machine is simply left on so it doesn't need to download the "knowledge base" each time a user wants to know how a work flow was implemented last time. Since a second machine and screen is used you could charge additional license fees.  If the user can get more done each day by running a second application on second machine it should pay off since first machine used for work orders and IT work done concurrently on second machine albeit losing their "knowledge base" view when backing up.  In short, Historian functions adds a lot of overhead in bandwidth and screens!   

[Remy Lebeau 1436]

22 hours ago, Ian Branch said:

The methodology was developed for a specific purpose, to determine the User's choice before the form was constructed/shown.

Nothing wrong with having a dialog for that. But displaying it directly in the constructor of a Form while it's being created is not a good choice, especially if you want to cancel that creation.  Better to have the caller display the dialog first, and if it is not canceled then create the Form, passing it the dialog's selected option.

 

If you really want to be able to reset the Form with a new table without closing and recreating the Form,, then you should move that logic into a separate method of the Form, and then call it when needed, ie when the Form is shown, and in a button/menu handler on the Form. I wouldn't call it directly in the constructor, though, but the constructor can trigger it asynchrously, such as with PostMessage() or TThread.ForceQueue(), so the Form can be constructed normally. Or use the Form's OnShow event.

Edited August 17 by Remy Lebeau