<<<
This means adding _new parameters to existing functions
should be avoided_.
As I said it does not break anything and we have nothing to
change in C code exept for PRG callable functions like
DispOut(),DispBox() etc.
_"Except for DispOut/DispBox()?"_
There are thousands of such calls in every application.
If changing these wouldn't quality as "break anything" I
don't know what would do.
hb_wSelect( [<nNewSelectedWnd>] ) -> nPrevSelectedWnd
This is the area where I totally disagree.
Xbase++ implemented it in their much propogated
campaign to lure Clipper programmers but it is totally
a frustration. In the modern era we need to match
I use this method since 15 years, and there is zero
frustration as most of the time I open a windows, write
to this window, close the window, and I get back the
focus of the original one automatically. So in actual
.prg code I only use Open/Close, but never Select().
wSelect() is only needed if I want to display stuff in
other windows than the current, which is pretty rare.
the current presentation protocols. For example, how
will you control if the user clicks on other appln window?
For every GT command you cannot match a
hb_wSelect() as in m-w environment the program
flow is controlled the user instead of application.
I'm not talking about GUI applications, but rather
modal CUI applications. Where one windows is active
at a time, clicks can only be accepted by current
window.
Again, baby steps please, it looks you're trying
to get the Windows concept into Harbour core.
Which I'm totally against.
We need not to define anything. Przemek has already
done it in GT core ad is perfect.
huh?
The current GT is perfect, I was talking about moving
windows support to GT core, rather then having it
implemented as a layer above. This raises some question,
these are a few of them.
This is where I strongly differ. All existing GT methods are
capable of setting/returning values of respective window. However,
hb_wList() -> <aWnd> (list of all open windows) will be an
additional one. It can also go into core.
GT methods on the C level and "GT methods" (display functions)
on the Harbour level are two different things. C level should be
extended (hb_gt*()), while keeping compatibility with legacy GT
API (_gt*()). This seems easy.
For the Harbour level though, we need to keep compatibility
with existing code. Part of this compatibility is that we
don't introduce "hidden extensions" to existing functions.
For this reason DispOut() parameter list for example cannot
be touched.
If you personally favour extending DispOut(), you can create
#translates DispOut( "text", color, wnd ) => hb_wDispOut( wnd, "Text",
color" )
I ever longed for this functionality but found the
solution in palette only. It will be nice to see this
capability in core but for sure it will break a lot of
existing code.
It won't break any code, as the numeric colors
would only be supported in new hb_w*() functions.
C level GT API functions need not to be changed.
I cannot even how you'd do that.
Only PRG callable C functions need one more parameter.
DispOutAt( nRow, nCol, xVariable, cColor[, hWindow ] )
DispBox( ...[, hWindow ] )
and so on.
If [hWindow] is omitted, base window is the output surface.
Sorry Pritpal, but you seem to not recognize a very
important rule, we've been discussing a lot and which
we're working since the very start of this project:
Compatibility.
Important, but natural property of the multi
window GT is that all windows will be "buffered".
GTs will need to be extended to render these
buffers on the available output buffer (or
display the separately, by using f.e. Windows API
to render them).
This is already there. Each window has its own buffer.
There is no window support in any of the GTs,
besides ctwin. What window are you referring to?
"window" means a selected and separately handled
area inside a CUI box. I'm not talking about
window in any GUI terms.
Yes. To implement this is much easier.
SUMUP:
For multi-window to be a success it is important
that user be able to control the flow of operations
instead of program code.
The other important thing is to adhere to some basic
rules of Harbour development, rather than being caught
by easy and quick features tackled into the Harbour
core, which will create problems later, or the some
of the main goals and properties of Harbour will suffer
(like portability and compatibility).
Your multwvt is example is interesting, but it's mixing
different concepts, like callback based input handling
(Windows-style), which I personally find extremely
counter-productive to use in a real application, and
non-modal Windows in a single threaded app. I don't
like it, and all I'm personally proposing is to move
ctwin-like logic to core Harbour, and see where to
go next, as your move seems to raise a lot more questions
than it solves, and I'd better like to discuss these
step-by-step.
So again: I'm proposing to add ctwin-like windowing
to core, with no messing with callbacks and input routing,
or moving to a GUI-like direction in one step. And
while keeping the Harbour interface compatible, with
no hidden extensions, extra parameters.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
