Circle diameter versus radius -- also GTWVG

[elch]

Hi,

hb_gfxCircle:

absolutely no topic to change my few lines with diameter style to radius,

to adopt supposed in changelog.

But it seems that nearly everywhere in Harbour it was implemented as diameter

for circles & ellipses. At moment f.e. also still in GTWVG. And even in the

tests/gfx.prg i can read a 'height' for a circle and 'width' for ellipse as

var names ?

This doc you mentionend, Viktor, i very like to read - where to find ? -

because i poorly only know the testdemo and a bit Harbour source of used GTs'.

--

Difficult question (to Pritpal ?) about all hb_gfx* in GtWVG:

If i use them as designated they are not persistent, means i can wipe them

away with another window using that as cleaning rag - even when i set

Wvt_SetGui( .T. ).

I discovered another device context (DC), this item: pWVT->hGuiDC.

Using this in opposite to pWVT->hdc, drawn graphics do not appear. But now i

can wipe them to appear :-)

So i actually work around using both in an own version of gtwvg, drawing two times the same with obviously different DCs' -- a simple trick left i haven't found yet ? Or is this maybe only on my Windows machine ?

Regards

Rolf

[vszakats]

Hi Rolf,

On Wednesday, March 6, 2013 10:10:23 PM UTC+1, elch wrote:

hb_gfxCircle:

absolutely no topic to change my few lines with diameter style to radius,

to adopt supposed in changelog.

But it seems that nearly everywhere in Harbour it was implemented as diameter

for circles & ellipses. At moment f.e. also still in GTWVG. And even in the

tests/gfx.prg i can read a 'height' for a circle and 'width' for ellipse as

var names ?

This doc you mentionend, Viktor, i very like to read - where to find ? -

because i poorly only know the testdemo and a bit Harbour source of used GTs'.

It was Przemek's commit, so I have no idea, maybe this?:

   http://x-hacker.org/ng/53guide/ng4e643.html

1. I tend to be on the side that previous behavior was more 

intuitive and consistent with other tools, ie. when you 

specified the containing rectangle for a circle/ellipse, instead 

of the radius. BTW hb_gfx*() API is not a replica of above 

C5.3 API, so compatibility with it is not a must, though 

it's possible these are not the docs referred to.

2. GTWVG implements "inheritance" from GTWVT by 

copy/pasting source (twice) and extending it, so it constantly 

and manually needs to be updated when GTWVT gets changed. 

Proper solution would be to rewrite the two GTWVG GT drivers 

to truly inherit from GTWVT (meaning without triplicating 

thousand of lines of code via copy/paste).

-- Viktor

[Pritpal Bedi]

Hello Viktor

2. GTWVG implements "inheritance" from GTWVT by 

copy/pasting source (twice) and extending it, so it constantly 

and manually needs to be updated when GTWVT gets changed. 

Proper solution would be to rewrite the two GTWVG GT drivers 

to truly inherit from GTWVT (meaning without triplicating 

thousand of lines of code via copy/paste).

True.

But the question is how to inherit a GT. And more specifically

how to overload a method. In the end, almost all methods will be 

overloaded, I suspect, barring a few ones.

Pritpal Bedi 

[Pritpal Bedi]

Hi

Difficult question (to Pritpal ?) about all hb_gfx* in GtWVG:

If i use them as designated they are not persistent, means i can wipe them

away with another window using that as cleaning rag - even when i set

Wvt_SetGui( .T. ).

Because these components are not the part of 

GtWVG GUI engine, and so are not persistent. These can be made 

persistent, no doubt, and I sent a request to Giancarlo when he 

implemented them in GT, but he did not noticed.

In some spare-time I will try to add persistency to them.

 

I discovered another device context (DC), this item: pWVT->hGuiDC.

Using this in opposite to pWVT->hdc, drawn graphics do not appear. But now i

can wipe them to appear :-)

So i actually work around using both in an own version of gtwvg, drawing two times the same with obviously different DCs' -- a simple trick left i haven't found yet ? Or is this maybe only on my Windows machine ?

These two are for different usage and I am afraid you will make a mess 

of your code by using them directly. Instead use Wvt_* graphics functions

as demonstrated in wvgdemo.prg++. 

For quick understanding - note that GUI components are drawn on top 

of GT console buffer AFTER buffer is painted first, via mechanism 

adopted in demowvg.prg++.

Pritpal Bedi

[elch]

Thanks!, Pritpal

for fast answer. I will search for what you advices.

And no, i can't use that personally very important hb_gfx* draw functions directly.

Instead actually operating with an minory altered GtWVG.

And GtWVG seem to be the more mighty gtwvt, here i have all together what i need.

best Regards

Rolf

[vszakats]

Hi Pritpal,

On Thursday, March 7, 2013 4:03:17 AM UTC+1, Pritpal Bedi wrote:

But the question is how to inherit a GT. And more specifically

how to overload a method. In the end, almost all methods will be 

overloaded, I suspect, barring a few ones.

You can see the technique in hbct with ctw.

-- Viktor

[elch]

Hi Viktor,

that you can better imagine, what i mean with 'wiped away', i attach a picture of GTWVT.

In GTWVT exists no Wvt_DrawImage, so i only can use Fi_WinDraw().

Why the bitmap drawn with Fi_WinDraw() is not persistent, is maybe explainable. Because i am after weeks of research poorly not able to get the correct device context out of gtwvt and reach it through to this function in hbfimage -- in result the bitmap is drawn at area of window, but not IN window.

Exist there _any_ example code anywhere ?

More question to you, or please direct it further to anyone who maybe know:

any suggestions please why the gtwvt hb_gfx* drawn things [coloured objects in middle] are not persistent ?

What do i make wrong, or better better ?

In GTWVG i found a solution for all, perhaps not fine but seem to work well.

For GTWVT i have not any idea where to search further, seem to be a graphical terminal but only for text ...

Regards

Rolf

[vszakats]

Hi Rolf,

On Friday, March 8, 2013 10:52:09 PM UTC+1, elch wrote:

that you can better imagine, what i mean with 'wiped away', i attach a picture of GTWVT.

In GTWVT exists no Wvt_DrawImage, so i only can use Fi_WinDraw().

Drawing on a GTWVT window from outside the realm of the
GT driver itself, is not something that's supposed to work.
The window is managed by GTWVT, and it doesn't know what
you drew upon it via direct Windows API calls, consequently it
cannot f.e redraw those, when the OS requests it.

Hence there is GTWVG, which promises to support such things.
 

Why the bitmap drawn with Fi_WinDraw() is not persistent, is maybe explainable. Because i am after weeks of research poorly not able to get the correct device context out of gtwvt and reach it through to this function in hbfimage -- in result the bitmap is drawn at area of window, but not IN window.

Exist there _any_ example code anywhere ?

No, see above. It's also not incidental that there is no
way to query the window handle via public GT API.

More question to you, or please direct it further to anyone who maybe know:

any suggestions please why the gtwvt hb_gfx* drawn things [coloured objects in middle] are not persistent ?

What do i make wrong, or better better ?

To me it looks like a bug/missing feature, but drawing
graphics on a GUI is a very niche feature, so either nobody
cared to implement such support, or it was a design
compromise made intentionally in the past. I'm just
guessing it's the former.

In GTWVG i found a solution for all, perhaps not fine but seem to work well.

For GTWVT i have not any idea where to search further, seem to be a graphical terminal but only for text ...

I'm not sure why you want to use GTWVT. If my eariler
post was confusing, what I wanted to say is that the way
GTWVG is implemented is not right. It's _copy/paste_ code
from GTWVT, instead of internally _inheriting_ from that
GTWVT. It causes that GTWVT source updates needs to
be always applied _manually_ to GTWVG. It's code may also
go out of sync until a manual source code sync is made.

Apart from that aspect you can _use_ GTWVG just fine.

-- Viktor

[elch]

Hi,

combining your both answers i just got an immedeate glimpse where the origin of all my problems may lay.

THANKS!, masters of source.

It is because Windows API seem to be so fundamental different to X11 style of thinking.

In X11, after a call to the central X11 Server, which redirect this to the WM:

'hello, i have here a bitmap i want to be displayed in my window at position ...' - and it accepted that because bitmap is valid - all is done !

Even if app stops working after that moment, the content of the window will be well refreshed by WM when moving around another [my personal hit: translucent] window above.

---

> To me it looks like a bug/missing feature, but drawing

> graphics on a GUI is a very niche feature, ..

To display graphics with some simple primitives on it, or to have another windows on screen: Viktor, what did you mean is 'niche' ?

Doubtless revolutionary, because with this my Clipper [Harbour] apps after decades finally enter next, perhaps ultimate stage,

even without gui MENU with sometime confusing many colourful buttons - is a long time missed 'feature'.

Click-able menu items or displayed F-keys at footer, no topic is a must nowadays.

And probably, i am at all 'niche' ;-) - where else is really something left to develop ...

+++

Dear Pritpal,

before loosing valuable spare time for these hb_gfx* parts ..

I _much_ more miss the feature to resize the window back to dimensions it had before maximizing it.

This would perhaps benefit more users, not only me.

I am in big doubt i can do it, but perhaps you can try to give me a quick impression where to implement that.

I read at another older thread it would be much work, and you seem to have less spare time ...

best Regards

Rolf

[vszakats]

> To me it looks like a bug/missing feature, but drawing

> graphics on a GUI is a very niche feature, ..

And of course I meant CUI.

-- Viktor

[elch]

One last shot, know i'm leaving topic of thread ...

> To me it looks like a bug/missing feature, but drawing

> graphics on a GUI is a very niche feature, ..

And of course I meant CUI.

 

agree ! - now and in near future i explicitely want to have a:

fast !, super accurate and most reliable 'CUI-alike' based system.

You suppress a bit that the mentioned GTs are internally 'under the hood' more GUI than CUI.

F.e. all work with text INTed mouse pixel coordinates.

I only like above that CUI style a bit enhancement, call it 'E[lch]-CUI', means:

pixel mouse coordinates on demand (with a seperate request),

[big] bitmaps in defined screen area at special occasions,

plus some graphic primitives including small amounts of text at pixel coordinates.

This i have ready in gtxwc, gtwvt and really most was ready in gtwvg.

Only in gtwvt nothing of that stays persistent, as very opposite to gtxwc.

You perhaps overlooked my numbers very precise in center of wiped circles ? ;-)

That's all i need for my personal revolution ...

best Regards

Rolf

[Pritpal Bedi]

Hi

+++

Dear Pritpal,

before loosing valuable spare time for these hb_gfx* parts ..

I _much_ more miss the feature to resize the window back to dimensions it had before maximizing it.

This would perhaps benefit more users, not only me.

I am in big doubt i can do it, but perhaps you can try to give me a quick impression where to implement that.

I read at another older thread it would be much work, and you seem to have less spare time ...

This is really a difficult process if not impossible.

Anyway I will look into this next week, keep me awake, if I 

could implement that.

Pritpal Bedi

[vszakats]

On Monday, March 11, 2013 8:58:22 PM UTC+1, elch wrote:

One last shot, know i'm leaving topic of thread ...

> To me it looks like a bug/missing feature, but drawing

> graphics on a GUI is a very niche feature, ..

And of course I meant CUI.

 

agree ! - now and in near future i explicitely want to have a:

fast !, super accurate and most reliable 'CUI-alike' based system.

You suppress a bit that the mentioned GTs are internally 'under the hood' more GUI than CUI.

F.e. all work with text INTed mouse pixel coordinates.

GTWVT uses GUI Windows APIs to draw the CUI console,
that's all. This fact doesn't define or redefine the goal of core
of this core GT. The goal remains to draw the oldschool CUI,
only in a more flexible and quicker way that the dedicated
CUI ('Console') Windows API allows. Another primary goal
is to keep the GT _replaceable_ that means an app written
for GTWVT should be able to run unmodified when using
another GT.

As a non-core GT, GTWVG doesn't have such restriction so
it can and does offer special features.

I only like above that CUI style a bit enhancement, call it 'E[lch]-CUI', means:

pixel mouse coordinates on demand (with a seperate request),

[big] bitmaps in defined screen area at special occasions,

plus some graphic primitives including small amounts of text at pixel coordinates.

This i have ready in gtxwc, gtwvt and really most was ready in gtwvg.

To me these seem to fall out of the goals of GTWVT,
except the redraw issue, which should ideally work
properly if half of the feature is already implemented.
But as much as know about the Windows API pbly
it's a not a 5 minutes fix, but I may be wrong.

BTW, by niche I mean _very_ few people use it. F.e.
drawing in GTWVT was broken for 1.5 year Harbour
(including one stable release), and nobody every reported it.
It wasn't broken subtly: It didn't draw anything.

> You perhaps overlooked my numbers very precise in center of wiped circles ? ;-)

> That's all i need for my personal revolution ...

I should have put a TL;DR, I admit I didn't read the whole thing, sorry.

-- Viktor

[Przemyslaw Czerpak]

On Fri, 08 Mar 2013, elch wrote:

Hi,

> It is because Windows API seem to be so fundamental different to X11 style
> of thinking.
> In X11, after a call to the central X11 Server, which redirect this to the
> WM:
> 'hello, i have here a bitmap i want to be displayed in my window at
> position ...' - and it accepted that because bitmap is valid - all is done !
> Even if app stops working after that moment, the content of the window will
> be well refreshed by WM when moving around another [my personal hit:
> translucent] window above.

The real answer is trivial and very far from above.
In both GTs system asks to redraw some rectangles sending expose events.
GTXWC does not write data directly to the window but operates on internal
image which contains console window output and GFX primitives so on expose
it simply copies requested region from internal image to the window.
GTWVT writes data directly to the window so it cannot restore GFX objects.
GTWVG just like GTXWC uses internal image with window contents.

best regards,
Przemek