Hi Przemek,
One simple example I've just tried:
---
PROCEDURE Main()
LOCAL var := Space( 10 )
@ 10, 10 GET var ; DispOut( " unit" )
RETURN
---
There are lots of similar places, where caller
could so far expect the cursor position to be left
at where it was in Clipper. Now, since only hb_*()
display functions are used in these areas, and it
doesn't move the cursor, the cursor is left where
it was set last time, by the caller .prg.
Few other, more specific issues:
Speed: now hb_gtPutText() will save/set/restore the
color, and the new caller, hb_DispOut() will also do so.
Is the latter necessary BTW? To me it seems like it's not,
anymore.
It is original DISPOUT() behavior replicated which I changed
and committed few minutes ago.
Thanks, I've seen it, and it's exactly what I had in
mind.
Anyway, since color is a string in Harbour, any code
touching it is costly. Do you think it'd be possible to
change colors internally to some more machine friendly
format, like simple ULONG, or string of ULONGs? Not on
the short-term, but generally.
I think INT will be enough as index to internal GT color table.
Many functions support both: color as number and as string.
In HB_SCROLL() code you will find an example of color decoding
I'm trying to use systematically in such case. Now it works
for internal numeric color representation (VGA) but it should
work also for any other when we introduce it.
Okay, any numeric will be just as good. I've checked and
it's also exactly what I had in mind. Shouldn't we also use
a numeric in the new parameter of hb_gtPutText() and the
new hb_gtDrawBox()? If we would have new hb_gtSetColor()
and hb_gtGetColor() GT API functions operating with
numerics, most cases would be covered.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
