XHarbour 98% 1

[Frandalf]

Hi everybody,

I got my Clipper app about 98% migrated to XHarbour (org).
A few things are still not working:

In my program, I use hotkeys wich I want to be accesible from the GET fields. I did this by writing my own inkey() function and replacing GETSYS.PRG with my own MYGETSYS.PRG in wich the calls to inkey() where replaced with calls to my inkey() function.
In XHarbour now, when I replaced the getsys with my own MyGetSys.PRG but this doesn't seem to work. The module gets compiled and linked-in, but the standard ReadModal() is not replaced. In fact, I think XHarbour uses anothet GET system all the way.
So, my hotkeys work everywhere I replace inkey() with MyInkey(), but not from GET input fields.

How can I make my hotkeys() accesible from GET input fields?

Thanks for any respons.

 

[TonHu]

You should be inserting your ReadModal into your app with an obj file, instead of a library, as I did the same trick, and it does work as expected ;-)
I'm not close to my clipper-sources, so can't tell the exact details. I'll try to look that up later. May pass the weekend though, as I'm not sure when I have time (got those sources at home).

HTH
TonHu

 

[Frandalf]

Thanks again, TonHu,

Please take a long weekend. I'm not in a hurry.


Meanwhile, I solved the ReadModal() problem (it was old undocumented code and I should have re-studied it better before asking for help).

But now we come to a more important point, I think...

I found out that I had other functions in my libraries wich didn't work as I expected anymore... Until I discovered that they were actually existing (xharbour) functions with the same name that were giving me the result!! WCol() and WRow(), for example.
Without thinking, I renamed my functions all over (WinCol() instead of WCol() etc...) and they worked again.
But, actually, this is the same problem as with ReadModal() in getsys.prg as you pointed out.

So, what I conclude (maybe too early) from this:

1:
I can unpunished, in a .LIB file, define a function wich already exists in xharbour. I get no complaints during compile/link. But my function is ignored and the original xharbour function prevails (so I DO het punished!). Shouldn't I get a warning at least? (function override, function already exists, duplicate definition, or even: function override not allowed in libraries. WHATEVER?)

2:
I can, on the other hand, define my own function and override the existing xharbour function (readmodal(), WCol() etc...). But then I have to do it in a separate (non .LIB) module.
Wich comes down to not being able to write libraries as one should!

3:
I'm probably panicing too soon.

 

[TonHu]

All sympthoms you describe in 1: and 2: are the documented behavour rules for lib's used by a linker. The object actually used is the first one found, and libs are scanned from left to right, as placed in the list. So no warning is to be issued by the linker.

Forcing your functions to be used instead of the xHarbour ones would involve placing your lib *before* the xharbour runtime libs. This is not the advised method; you should be linking in .obj files directly, which already have precedence over lib-files by rule. Using older linkers (IIRC Blinker) even allowed me to force all modules from a lib into an exe by specifying that lib as an obj-file (file=mylib.lib in place of lib=mylib.lib or search-mylib.lib) but this isn't supported, at least not by the Borland linker iLink32.

You followed the best solution: rename your functions inside your lib. I had the same troubles in a far past, but prefixing them (I used a company default of 'BK' giving BKRound f.i.) should be the final cure for this. For this same reason, lots of (x)Harbour functions are called HB_somefunc, just to avoid these name-clashes.

HTH
TonHu

 

[Frandalf]

Thanks TonHu,

I didn't realize that the linking system worked that way but apparently it does. No problem, I'll try to remember that now.
When I come to think of it, I may have accidently used functions in my libraries that already existed in Clipper!
I probably didn't, but in this new xharbour environment, it could happen easily. I better check out if a function exist before I make it myself!
And now I better start examining my libraries for more existing xharbour functions that no longer work as expected. Maybe xharbour delivers the same functions with just a subtile difference wich would only show up every now and then? A programmer's nightmare, but I'm probably too pessimistic now.