I've never tried this type of thing before, but I have need to have an object free self.

After freeing any resource used by the object in it's Destructor, I call inherited destroy and it looks like the inherited destroy methods works, but right afterward, get a sig exception in LCLProc.unit:

function TMethodList.Count: integer;
begin
   if Selfnil then
     Result:=FCount <== here
   else
     Result:=0;
end;

Is it even possible to have an object free itself?

BTW, I'm trying my hand at creaing an MVC and I need the controller to be able to free itself because it is the object that 1) Creates the View (form) and 2) the Model (object) and mediates between them.

When the form is closed, the controller is notified and need to 1) free the form
2) free the model/object and 3) free itself.

Otherwise, I guess I must create some kind of manager object/list to free the controller from the outside. Note: If I free the controller object from outside (like putting it in an objectlist and calling ObjectList.clear) there is no exception.

Just calling free from the object itself poses the problem.

Thanks for input.

Never mind, I just saved myself a bit of aggravation and created a list manager for my controllers which works nicely and free everything from the outside without problems.

Thanks,

2008/5/15 Lee Jenkins :

I've never tried this type of thing before, but I have need to have an object free self.

Not allowed, as far as I know. The execution point has nowhere to return to after the 'inherited Destroy' line and before the 'end' of the destructor.
As another object to destroy it. eg: I use something similar in fpGUI. I post a message to the fpgApplication instance and request it to free of a modeless form (create for CreateForm()).

BTW, I'm trying my hand at creaing an MVC and I need the controller to be able to free itself because it is the object that 1) Creates the View (form) and 2) the Model (object) and mediates between them.

Out of interest. Have you had a look at MGM (Model-GUI-Mediator) yet? I'm using it in our current projects and having great success with it. MGM fits in somewhere between MVC and MVP. I think it ties in much better with todays more advanced GUI toolkits. It's also very simple to implement. tiOPF contains an implementation using RTTI to automate a lot of things, but a much simpler implementation could have been used as well.

More info on MGM at: http://www.atug.com/andypatterns/mgm.htm

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Yes.
In fact, it does not matter who frees it. Just make sure, all refences to the object are set to nil.

Create a backtrace. Find out, where something accesses the control after it has been freed.

Mattias

Damn, I spoke too soon. Its still doing it. Apparently, I just cannot call any kind of code from within the object that somehow frees it?

Is there any way around this?

OK, then there must be a something that is still referencing the object somewhere. I'll check.

Thank you.

Mattias Gaertner wrote

Create a backtrace. Find out, where something accesses the control after it has been freed.

Odd. Not much information from a backtrace:

Program received signal SIGSEGV, Segmentation fault. 0x00440cc5 in TMETHODLIST__COUNT (this=0xf0f0f0f0) at lclproc.pas:665 665 lclproc.pas: No such file or directory.

[...] > When the form is closed, the controller is notified and need to 1) > free the form 2) free the model/object and 3) free itself.

Ehm. Please explain 'when the form is closed'.

A lcl form is not a single object.

Mattias

Granted. What I'm trying to do is control the creation of the form and the object that the form is a view of from within the controller.

1. Controller is created.
2. Controller create the object/model.
3. When the form is closed the controller destroys the form and the model and then frees itself.

Currently, I'm hooking into the form's Onclose event with a method in the controller with the same signature. When the method is fired, the controller frees the form and the model/object then frees itself.

I guess I could create the controller from within the form/view, but that seems to defeat the idea of MVC.

Nope, when destructing, you destroy the data instance of your object, not the code. So the code will continue, however you cannot axxess any field of your object anymore.
(what I wrote is valid for classes, for objects you cannot acces virtuals either)

Marc

Please keep in mind, that you can not free a control, during an event for this control. (Some events on some widgetsets allow this, but this can change in future so I won't count on it). But you can free it later, using Application.ReleaseComponent(AControl).

For example:

  Form1.Close;
  Application.ReleaseComponent(Form1);
  Form1:=nil;

The Form1 will continue existing and will be freed on next idle.

Mattias

Neat. I'll see if I can work that in somehow.

Thanks Mattias.

Worked like a champ. Thanks!

Well, I'd say yes since I use MGM with tiOPF all the time :) Actually, I'm still using them within the Form/View of my MVC implementation, but MGM didn't seem quite as suited for the job of mediating an entire form whereas MVC did.

The problem that I have is that I want to be able to completely rid my forms of as much code as possible, but I end up with a lot of MGM mediators that I still have to instantiate from within the form's OnShow event. So now I have:

|--Model = TtiObject/List. Model/Domain Logic.
|
View/Form
| |
| |----MGM Mediators Dummy View.
|
Controller
|
|---(Instantiates Model)
|---(Creates Form/View)
|---(Instantiates Mediators between Model & View)
|---(Hooks up/Handles View Logic/Events like Button clicks) |---(Tears everything down when finished)

I just create a TMVCController and it takes care of creating the Model, the form/view, hooks up and handles the Form/View's events and now with Mattias' excellent advice, handles the form's OnClose event and tears everything down.

I wouldn't call it a pure MVC, but for my purposes it seems to work pretty well.

Umm, never to old to learn something new. Thanks for the explanation Marc.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Lee Jenkins wrote

Well, I'd say yes since I use MGM with tiOPF all the time :) Actually, I'm still using them within the Form/View of my MVC implementation, but MGM didn't seem quite as suited for the job of mediating an entire form whereas MVC did.

My Forms contain less and less code by the day. To solve the long standing issue of instantiating those mediators, I've played around with the idea of having some design time component I can drop on a form and hooking up the components that need to be used as 'views'. I started off by using some registry for helper objects so I don't actually have to know which mediator gets used for which object property. It's not 100% complete, but I believe it's heading in the right direction. ;-)

As a side note:
I'm busy writing articles on MGM, MVC and MVP. For the MVP article I'm trying to coincide it with a MVP implementation for tiOPF. I've finally started understanding the different parts involved in MVP!

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

That's not fair, I wanted to implement this !!!
For once I had something fun scheduled at my job... :)

Will you include your implementation in tiOPF ?

Michael.

Michael Van Canneyt wrote

That's not fair, I wanted to implement this !!! For once I had something fun scheduled at my job... :)

The job is still all yours! I simply quoted your idea. :) I haven't really written much, simply a bit of concept code. As I mentioned, simply playing around with the idea. At the moment, I don't have the time for a full implementation, so looking forward to what you come up with. ;-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Good :-) I'm sure we'll still be in contact about this :-)

Michael.

Oooh, that sounds like fun. I look forward to seeing something when its ready!

Using the MVC approach, one challenge I came up against was replacing the "Owner" parameter functionality of the form's constructor. I find it convenient to use this with List Forms where I could have multiple edit forms open which represent individual objects in the list form. This was to ensure that if the list form is closed, any edit forms associated with the list form's objects are closed automatically as well.

I ended up creating a TMVCControllerManager where I can register controllers like this:

gMVControllerMgr.AddController(AController: TMVCController;
   const AKey, AGroup: string);

This allows me to free a controller (and its model and view) or a group controllers easily. I copied the "group" concept from tiVisitorManager...

I'd very much like to see yours or Michaels' implementation when it finished. MVP has quite a few "moving parts" from what I've read.