Hi Przemek, Thanks for the clarification about HB_HRBDO(), my mistake.
You where right, Hrb file was closed by the garbage collector. The call to hRb was done from a function wich stored pHrb into a local var, saving Hrb pointer to some static var solved the problem. Finally, I even don't need to use HB_HrbDo(), just loading the HRB and unloading it at the end of the program is enough. Many thanks for the clarification, Regards, JF, -----Message d'origine----- De : Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] Envoyé : mercredi 13 mai 2009 12:34 À : Harbour Project Main Developer List.; J. Lefebvre; Phil Barnett Objet : Re: [Harbour] HRB problem with inherited classes On Wed, 13 May 2009, J. Lefebvre wrote: Hi, > This mail seem to never reach the list ... New test ! > ++++++++++++++++++++++++++++++++++++++++++++++++++++++ And it's very serious problem. I still cannot see some messages I sent to this list in last days. They are not available also on http://lists.harbour-project.org/pipermail/harbour/2009-May. Phil please look at it. The messages does not appear at all or are delivered with huge delay. The same was happening in the December and then the list died. > I'm working with HRB files and suddently discovered a serious problem when > using Classes defined within the HRB files inheriting from classes from the > main program. > Suppose we have those two classes, Dialog within the main exe, and MyDlg > from the HRB file. (This sample is NOT tested nor compiled, it could > contain errors, just here to explain the problem !!!) > > Main prog ; > Class Dialog > VAR x > Method New() Inline x:=1, Self > Method Destroy() > Method OnClose() INLINE .F. > endclass > > Method Destroy() Class Dialog > if(::Onclose()) > x:=NIL > endif > Return Self > > > HRB prog ; > Class MyDlg inherit Dialog > VAR y > Method New() INLINE y:=1, Super:New() > Method OnClose > Endclass > > Method OnClose() Class MyDlg > Return .T. > > When Running the (similar, bug much much biger) prog, at the time of > Calling Destroy() method, the super class method is used, so ::Onclose() > is called and the class hierarchy is working nicely, to use the onclose() > method defined in MyDlg class, within the HRB file. > > Then, class system is looking for the associated static function > MyDlg_Onclose() defined within the MyDlg Class Header and ... > IT DOES'NT FIND IT (as expected) because it should be called by > HB_HrbDo(...) and not directly ... The above is not true. There is nothing what has to be called by HB_HrbDo() The above function does not make anything more then executing the 1-st non static function from the .hrb file. The only one functionality given by this function is executing the 1-st function from loaded .hrb file when it's not known at all. It does not provide any other functionality and is not necessary to use .hrb files. > Now some questions : > Could we imagine a system where we could create a new HBR function like > HB_HBRDYNSYMLOAD(cHbrFile) wich not only would load the HBR header, but > also would list all internal function and add them to main symbol list > (event more powerfull, it could replace some if some with same name exist, > allowing the HRB file to patch program easily) It works in such way. For HVM there is not difference between code loaded from .hrb files, static part of applications or shared libraries loaded statically or dynamically. The new functions are registered and are visible and usable as any other functions until module is unloaded. If module is unloaded the references to functions insiade the module are cleared so if they were stored in some other structures, f.e. in classes code or in some variables ( var := @myhrbfunc() ) then when you try to execute them you will have function not found RTE what is expected behavior. If the same modules is loaded again the all references are resotred automatically. > Where should I have a look if I want to add this kind of functionalities ? I can only guess that in your case the .hrb module was unloaded explicitly by your code or azutomnatically by destructor, f.e.: pHRB := hb_hrbLoad( cHrbFile ) [...] pHRB := NIL // activate automatic destructor which calls hb_hrbUnLoad() > I found runner.c but I have to > 1) scan HRB to list existing function, > 2) scan the actual symbol list and either replace some symbol or add > new symbol > Finally, I shoud be able to unload the HRB file and restore the symbol > list (but I can live without it :-) ). I'm sorry but I do not understand what you want to do in above. You can cleanly unload .hrb files at any moment. But if you will later try to execute some function or method from unloaded .hrb file using some references or macro compiler ( &("myhrbfunc")() ) then you will have Error BASE/1001 Undefined function: MYHRBFUNC or similar method/ivar not found. What seems to be nice and clean solution. Of cousre we can also replace unloaded functions with some dummy code but IMHO it's not good idea. > Apart the last point, this is how Blinker was working with blinker > special DLL for clipper. You can load a Dll with some code (new or > existing) and the loader add all the function and vars to the symbol > table, eventually replacing existing one. With Blinker, you CAN'T > unload it without GPFying your program !!! And with Harbour you can do it cleanly and if you try to access unloaded functions then you should have clean RTE: function/message not found. Of course it's possible the we have some bugs in existing code and we have GPF but in such case such I will need self contain example to fix it. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
