TPanel & Codejock

[TimStone]

Using: xHarbour(.com) August 2010 , FWH 13.04 build
With: Latest Codejock implementation from Richard CHIDIAK

This is an error that is not happening consistently. It occurs on two computers at a client's location.

When creating a new calendar window, the TPanel class is called :
::oPanelCalex = TPanel():New( 0, 175, ( nHeight ), ::oCwnd:nWidth, ::oCwnd:oWndClient )

Most of the time it works fine

Sometimes there is an error:
TPanel, Cannot find Window Class
TPanel:New( 49 )
:Create(739)
:createerror( 758)

Any thoughts on how to eliminate this problem ? Thanks.

[Richard Chidiak]

Tim

Make sure you have ::opanelcalex := nil in the end method

in my end method i have all these

::oCalexStdDlgs := nil
::oGlbSettings := nil
::opanelCalex := nil
::opaneldtp := nil
::oDtPick := nil
::oCalex := nil

my guess is that the customers enter and exit several times the calendar and if the object is not properly ended , at a moment it can not create it. (Just a guess, it fails at creation of the panel so it can make sense).

I do not have (so far) any of my customers reporting similar problem.

Hth

Richard

[TimStone]

::oCalex was not in my end

::oPanelDTP does not exist in my class.

Thanks. These people use the appointment scheduler very aggressively.

Tim

[James Bott]

Tim and Richard,

You should be calling the panel's End() method when you are done with it.

oPanelCalex:end()

I would not just set it to nil. The TPanel class doesn't have it's own End() method but it does inherit from TControl which does. And TControl's End() method also calls TWindow's End() method. There are routines in these two parent classes' End() methods that need to be called when a panel object is done.

You should always call the End() method of any object when you are done with it.

Tim, I don't know if this will solve your current problem, but it needs to be done anyway.

Regards,
James

[Enrico Maria Giordano]

You should always call the End() method of any object when you are done with it.

Not always. Often the owner takes care of releasing the object (at least in FWH).

EMG

[James Bott]

Enrico,

I knew you would get me on that one. Yes, you are correct, however, it seems easier to just to adopt a policy of ending any objects you create than to figure out if the owner object is doing it. Further, if you are having problems that seem to be helped by setting objects to nil, then you should be using End() instead.

James

[Enrico Maria Giordano]

James,

Enrico,

I knew you would get me on that one. Yes, you are correct, however, it seems easier to just to adopt a policy of ending any objects you create than to figure out if the owner object is doing it. Further, if you are having problems that seem to be helped by setting objects to nil, then you should be using End() instead.

James

Are you saying that we should explicit End() GETs, COMBOs and so on?

EMG

[James Bott]

Enrico,

Are you saying that we should explicit End() GETs, COMBOs and so on?

No, as you pointed out all controls on a dialog are ended by the dialog.

I do end fonts, panels, database objects, etc.

Like I said before, if setting an object to nil is helping, then one should be using end() instead.

James

[Enrico Maria Giordano]

James,

Enrico,

Are you saying that we should explicit End() GETs, COMBOs and so on?

No, as you pointed out all controls on a dialog are ended by the dialog.

I know that. I was joking.

I do end fonts, panels, database objects, etc.

Like I said before, if setting an object to nil is helping, then one should be using end() instead.

James

I agree. But as far as I know, setting an object to nil would help only if the variable hosting the object reference were STATIC. Otherwise, the garbage collector will do its good work when the variables goes out of scope.

EMG

[James Bott]

Enrico,

But as far as I know, setting an object to nil would help only if the variable hosting the object reference were STATIC.

I do see a lot of people using statics. I hardly ever do since I use mostly classes. All my class objects are Locals.

James

[Enrico Maria Giordano]

James,

Enrico,

But as far as I know, setting an object to nil would help only if the variable hosting the object reference were STATIC.

I do see a lot of people using statics. I hardly ever do since I use mostly classes. All my class objects are Locals.

James

So you don't need to set your variables to NIL.

EMG