On Thu, 17 Apr 2008, Phil Krylov wrote: > On 17/04/2008, Lorenzo Fiorini <[EMAIL PROTECTED]> wrote: > > We told about this time ago. > > This is what we get inspecting a tbrowse object: > > Error BASE/41 Scope violation (hidden): TBROWSE:ACELLCOLORS > > Called from TBROWSE:ACELLCOLORS(0) > > Called from __OBJSENDMSG(0) > > Called from __OBJGETVALUELIST(170) > > Called from HBDBOBJECT:NEW(84) > > ... > > Any workaround? > In xHarbour, this is solved using __SetClassScope() function which > temporarily disables class message scopes while in debugger. In > Harbour, it's #ifdef'ed out in debugger.prg because there's no such > function in Harbour. I don't know if it can be easily solved in > current Harbour's class engine.
Such functionality like in xHarbour can be added in few lines but it does not resolve the problem. In Harbour you have support for real private variables and methods. It means that child classes can have it's own messages with the same name as hidden messages in parents but it does not effect parent class code. When it calls one of such hidden messages then its own version is executed. It means that the same class can have more messages with the same name inherited from parents. If you disable scoping then only the last child message will be visible. xHarbour does not have such functionality at all and you can disable scoping at anytime. In fact they are not work as they should even enabled. If you want to see how it works in Harbour then please try tests/clsnv.prg It's very important feature. It means that working in a team you do not have to worry about name conflicts because all hidden messages belongs only to the owner and it's guarantied that they will not be effected by other messages with the same name which can appear in child or parent classes. The debugger is executing .prg functions which change execution context and classes code forbids to access hidden and protected messages. To really resolve the problem (without disabling scoping) we will need some mechanism to change current execution context to the code actually debugged before sending messages. I can write function which will do that but I need to know which functionality you need. It will be also usable in any OOP debugging because scopes will still work just like in normal code. In tests/clsscope.prg you can find test code which tests OOP scoping. You can try it also in xHarbour but you will have to divide classes in this file into separated .obj modules because xHarbour uses symbol table for scope checking instead of real stack execution context so it cannot work for the code which uses the same symbol table. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
