Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Budyanto, On 2008.10.29., at 4:21, Budyanto Dj. wrote: Hi Viktor, On 28 Oct 2008 at 21:27, Szakáts Viktor wrote: But why do you need to add all these non console related stuff to GTWVT?? I think Pritpal is trying to get into the scheme of "inherits from GTWVT to avoid duplicated code". IMO this way it's done the wrong way. For one, GTWVG has - from the beginning - lots of duplicated GTWVT code, which is still there. Secondly, point of inheritance is that generic features get implemented on the parent level, while speciality features get implemented on the child / inherited level. In this case speciality features seems to be (planned to be) implemented on the parent level, which is IMO not ideal. Rather, existing duplicate code in GTWVG should be eliminated, and replaced with GTWVG specific stuff. This may also mean that GTWVG could become a middle GT layer, just like CTWIN GT, but I don't know it enough to tell this. You're again and again trying to add Windows specific features to GTWVT, but such things simply don't belong there. GTWVT is a console emulation, and there is no need for any platform specific whistles and bells there. Rather the main point is that an application written for GTWVT can be ported to GTWIN, GTXWC, GTTRM without modification and with an equivalent feature set. If GTWVT is restricted to "console emulation only" then I wonder why we need to develop GTWVT? Why not using GTWIN instead which is a native console? Because it has quite some limitations (like screen size, limited fonts selection) and a worse "feel". GTWVT feels much more "native Windows", than GTWIN. It also allows for a WinMain() app to be built, which could have other advantages. We have an extremely flexible GT system in Harbour, so there is very few need to touch core code to implement special ideas beyond the core goals and scope. This is exactly done this way to let developers easily build upon in, and it's true for GTs just as well as RDDs, or our Harbour API. Isn't the GTINFO interface created with an idea that some feature(s) may be absent in some other GTs? It is. That's not really the question, the question is whether to implement special GTWVG (or Windows GUI) hb_gtInfo() features on the GTWVG level, or in GTWVT and core. Also lets not forget that if there are some features which get implemented on the higher level (in GTWVG), it may turn out to be useful and be moved "down" to core eventually, if all the obstacles and portability issues are cleared, etc. My 2 cents. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] How to get statistics
Hi, Which is the suiteable switch for get memory statistics? What I want to get is the amount of memory used by Harbour (stack, statics, items, etc), number of 'living' items, number of unrealeased items (if it is possible to know) at execution time. Thanks and regards, José Luis CApel ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Harbour under OS/2
[Maurilio] >I don't know, but GCC 4.3.2 from Paul is an alpha release, I'd wait for >a more stabilized environment. I tested gcc346, gcc404 and previous gcc432 and all were allmost unusable for Harbour Current gcc432 does things not so bad except for main error ld/emxbind Both gcc335 and gcc432 share same warnings, now fixed, and a few more in gcc432 so I consider it a great advance and is time to start reporting it >2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/contrib/xhb/xhbcopyf.c >! fixed name conflict with hb_fsCopy() >2008-10-28 15:56 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/include/hbstack.h >! fixed fDebugRequest declaration >2008-10-28 17:56 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/source/vm/dynlibhb.c >! added #define INCL_DOSMODULEMGR for OS2 builds Thanks Przemek Now current Harbour code build with just well-known warnings --- ../../gtstd.c: In function `hb_gt_std_ReadKey': ../../gtstd.c:389: warning: unused variable `TODO' - and same fixes apply to gcc432 Except for ld/emxbind error, rest are warnings I include them below so it can serve to fix something if it is a problem I do not know if same warnings appear in Linux/gcc4x builds or are just OS/2-gcc432 related David Macias ../../hbfsapi.c: In function 'hb_fsNameExists': ../../hbfsapi.c:323: warning: pointer targets in passing argument 1 of 'DosQueryPathInfo' differ in signedness ../../hbfsapi.c: In function 'hb_fsFileExists': ../../hbfsapi.c:381: warning: pointer targets in passing argument 1 of 'DosQueryPathInfo' differ in signedness ../../hbfsapi.c: In function 'hb_fsDirExists': ../../hbfsapi.c:440: warning: pointer targets in passing argument 1 of 'DosQueryPathInfo' differ in signedness ../../hbgete.c: In function 'hb_getenv': ../../hbgete.c:88: warning: pointer targets in initialization differ in signedness ../../hbgete.c:93: warning: pointer targets in passing argument 1 of 'DosScanEnv' differ in signedness ../../hbgete.c:95: warning: pointer targets in passing argument 1 of 'hb_strdup' differ in signedness ../../hbgete.c: In function 'hb_getenv_buffer': ../../hbgete.c:127: warning: pointer targets in initialization differ in signedness ../../hbgete.c:132: warning: pointer targets in passing argument 1 of 'DosScanEnv' differ in signedness ../../hbgete.c:136: warning: pointer targets in passing argument 2 of 'hb_strncpy' differ in signedness emxbind: invalid a.out file (startup code) ld.exe: emxbind failed make[3]: *** [hbpp.exe] Error 1 make[2]: *** [descend] Error 2 make[3]: *** [harbour.exe] Error 1 make[2]: *** [descend] Error 2 ../../hbffind.c: In function 'hb_fsFindNextLow': ../../hbffind.c:521: warning: pointer targets in passing argument 1 of 'DosFindFirst' differ in signedness ../../hbinet.c: In function 'HB_FUN_HB_INETACCEPT': ../../hbinet.c:1758: warning: pointer targets in passing argument 3 of 'accept' differ in signedness make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 ../../dynlibhb.c: In function 'HB_FUN_HB_LIBLOAD': ../../dynlibhb.c:104: warning: pointer targets in passing argument 3 of 'DosLoadModule' differ in signedness make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[1]: *** [first] Error 2 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 make[1]: *** [first] Error 2 make[3]: ../../../../source/main/os2/gcc/harbour.exe: Command not found make[2]: *** [descend] Error 1 ../../files.c: In function 'HB_FUN_SETFDATI': ../../files.c:273: warning: pointer targets in passing argument 1 of 'DosQueryPathInfo' differ in signedness ../../files.c:308: warning: pointer targets in passing argument 1 of 'DosSetPathInfo' differ in signedness ../../os2pm.c: In function 'HB_FUN_WINREGISTERCLASS': ../../os2pm.c:113: warning: pointer targets in passing argument 2 of 'WinRegisterClass' differ in signedness ../../os2pm.c: In function 'HB_FUN_WINCREATESTDWINDOW': ../../os2pm.c:148: warning: pointer targets in passing argument 4 of 'WinCreateStdWindow' differ in signedness ../../os2pm.c:148: warning: pointer targets in passing argument 5 of 'WinCreateStdWindow' differ in signedness ../../
[Harbour] problems generating demowvg
Hi all: i'm try to test demowvg from last svn and obtain this C:\harbour\harbour\contrib\gtwvg\tests>bld_b32 demowvg demowvg.c: Error: Unresolved external '_hb_ToOutDebug' referenced from C:\HARBOUR\HARB IB\B32\GTWVG.LIB|gtwvg Error: Unresolved external '_HB_FUN_HB_TOOUTDEBUG' referenced from C:\HARBO RBOUR\CONTRIB\GTWVG\TESTS\DEMOWVG.OBJ C:\harbour\harbour\contrib\gtwvg\tests> regards Ciro -- http://sistemascvc.tripod.com (la casa del clip2win y nodosimp / the no2imp and clip2win home ) http://www.oohg.org ( Object Oriented Harbour GUI, more simple, more powerfull ) ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] problems generating demowvg
Add hbdbgfx.lib in your link script. OR Comment out calls to this funtion in demowvg.prg. Ciro Vargas Clemow wrote: > > C:\harbour\harbour\contrib\gtwvg\tests>bld_b32 demowvg > demowvg.c: > Error: Unresolved external '_hb_ToOutDebug' referenced from > C:\HARBOUR\HARB > IB\B32\GTWVG.LIB|gtwvg > Error: Unresolved external '_HB_FUN_HB_TOOUTDEBUG' referenced from > C:\HARBO > RBOUR\CONTRIB\GTWVG\TESTS\DEMOWVG.OBJ > -- View this message in context: http://www.nabble.com/problems-generating-demowvg-tp20228112p20228909.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-10-29 08:10 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
2008-10-29 08:10 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED]) * harbour/contrib/gtwvg/tests/demowvg.prg ! Cleaned debug call left by mistake. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/2008-10-29-08%3A10-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp20229226p20229226.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] problems generating demowvg
Ciro Ciro Vargas Clemow wrote: > > C:\harbour\harbour\contrib\gtwvg\tests>bld_b32 demowvg > demowvg.c: > Error: Unresolved external '_hb_ToOutDebug' referenced from > C:\HARBOUR\HARB > IB\B32\GTWVG.LIB|gtwvg > Error: Unresolved external '_HB_FUN_HB_TOOUTDEBUG' referenced from > C:\HARBO > RBOUR\CONTRIB\GTWVG\TESTS\DEMOWVG.OBJ > Download afresh and build as bld_b32 -mt -gui demowvg -d__MW__ Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/problems-generating-demowvg-tp20228112p20229283.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] problems generating demowvg
Pritpal Bedi escribió: Ciro Thanks Pritpall best regards Ciro Ciro Vargas Clemow wrote: C:\harbour\harbour\contrib\gtwvg\tests>bld_b32 demowvg demowvg.c: Error: Unresolved external '_hb_ToOutDebug' referenced from C:\HARBOUR\HARB IB\B32\GTWVG.LIB|gtwvg Error: Unresolved external '_HB_FUN_HB_TOOUTDEBUG' referenced from C:\HARBO RBOUR\CONTRIB\GTWVG\TESTS\DEMOWVG.OBJ Download afresh and build as bld_b32 -mt -gui demowvg -d__MW__ Regards Pritpal Bedi -- http://sistemascvc.tripod.com (la casa del clip2win y nodosimp / the no2imp and clip2win home ) http://www.oohg.org ( Object Oriented Harbour GUI, more simple, more powerfull ) ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] How to retrieve - from PRG to C
Hello All
How I can retrieve pGT in c code sent via prg code.
Local pGT, pGT1
pGT := hb_gtCreate( 'WVG' )
pGT1 := hb_gtSelect( pGT )
hb_gtInfo( HB_GTI_PGT, pGT1 )
IN GT INFO METHOD
{
PHB_GT pGT = hb_itemGetPtr( pInfo->pNewVal );
// I do not receive pGT pointer. What I am missing ?
}
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/How-to-retrieve---%3CpGT%3E-from-PRG-to-C-tp20229416p20229416.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 29 Oct 2008, Szak�ts Viktor wrote: Hi Viktor and Pritpal, >> I think Pritpal is trying to get into the scheme of "inherits from GTWVT >> to avoid duplicated code". > IMO this way it's done the wrong way. > For one, GTWVG has - from the beginning - > lots of duplicated GTWVT code, which is > still there. And Pritpal wants to remove it and simply inherit from GTWVT. IMHO it's good idea. Now the proposed extensions. We already have in GUI based GTs extensions which are not portable to other GTs. F.e. you added font resizing to GTWVT when user changes the window size (just like in GTALLEG). I like this feature but it's not portable to other GTs like GTTRM/GTCRS/GTSLN which have to accept that terminal changes its state without our control and can be resized by user what usually changes number of rows and columns so it's compatible with previous GTWVT behavior. There are some differences between GTs and we cannot hide all of them. In this case we talk about three features: - passing style to console window so it can be tuned to look and behave like other OS windows - bounding console window with other group of visible objects or desktops - setting initial possition for new console window. For me all of them are important just like important is font selection or color palette setting. In some situations even much more important because without them it may not be possible to create console window at all in some environments, f.e. in XWindow I can display console window on different desktops, different XServers and different computers. If it will not be possible to control some of such local to given GT features then it may not possible to use some GTs. F.e. I can have application which works on remote server without any display adapter as daemon (service in Windows technology). On request this application can create console window using GTXWC on my local computer giving some functionality like online configuration. If I do not introduce some new features to GTXWC which are not available in MS-Windows/DOS world then GTXWC will not be usable for me. I will have to make copy of GTXWC for my own use to change only few lines just like now GTWVG is copy of GTWVT with some extensions. It's not good situation with also introduce other problems. Extensions will appear locally and will be strictly bound with given GTs so code using them will not be portable ot other GTs and platforms. We should try to reduce such situation and if possible try to define some interface which can be implemented also in other GTs which have similar possibilities. If sth cannot be well emulated by all GTs then we should add option which will allow to check GT capabilities from user code. F.e. just like now we can call hb_gtInfo(HB_GTI_ISGRPAHIC) to check if GT can operate on pixels or only on characters. It does not mean that we need all extensions in core code but we should allow to write 3-rd party / contrib code which can use core GTs as base. In this case I see why Pritpal wants to introduce such extensions and seems that the final results will be very interesting. Anyhow I do not like that they are such strictly hardcoded to be MS-Windows API parameters. In such case we will have similar set of parameters but incompatible also for XWindow and maybe MacOSX or OS2 if someone create GUI GTs for these systems. So I suggest to define what elements we want to set and use definitions with some meaning defined by us which then can be used with other GTs. So now we need: HB_GTI_WINDOWSTYLE We should also define our own styles HB_GTI_WS_* instead of using MS-Win constant values if we want to make this feature portable to other platforms. Please also do not start with whole list of all possible styles in some platform but use only these ones which are necessary and will be implemented and fully supported. As I can see we already have: HB_GTI_SETPOS_XY / HB_GTI_SETPOS_ROWCOL Looks that it's enough for basic window positioning. Pritpal, what else do you need to control window creation? I think that predefined window classes can be covered by our styles (and it will be good for portability) but maybe I'm wrong. BTW we can add to GTWVT thread which will redraw all existing console window asynchronously to Harbour code. In such case it will process all window messages. This will have one side effect. It will not be able to execute .prg code from message loop because it's not HVM thread. So please remember that any code which uses notifiers will not be able to benefit from such functionality which cannot be enabled for it. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-10-29 17:06 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-10-29 17:06 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbcompdf.h
* harbour/include/hbexprb.c
* harbour/source/common/expropt1.c
* harbour/source/common/expropt2.c
! change the expressions precedence - references to variables were
wrongly marked as simple expressions
* harbour/include/hbexpra.c
! fixed protection against wrong static initializers. Now code like:
static s_var := { { func(), M->var } }
or:
static s_var := { "A" => { func() => M->var } }
or:
static s_var := { @M->var }
or:
static s_var := QSelf()
is not accepted by compiler and error is generated at compile
time instead of crashing at HVM startup when static variables
are initialized
best regards
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] MT extensions
Hi All,
I will want to introduce two extensions for MT mode.
1. allow to use hb_mutexCreate() as static variable initialization.
It should help in writing MT code which have to use mutexes from
program startup and there is a problem with initializing them.
I added hb_threadOnce() function which resolves the problem but
it always has some speed overhead and make the code more complicated
then it can be. F.e. now we can write MT safe code which needs
static local mutex in the following way:
proc p()
static s_mtx, s_once
[...]
hb_threadOnce( @s_once, {|| s_mtx := hb_mutexCreate() } )
hb_mutexLock()
[...]
hb_mutexUnlock()
[...]
return
If we unblock using hb_mutexCreate() as static variable initializer
(now we can use only fully optimized functions: static s := HB_BITOR(1,2))
then the same code can be reduced to:
proc p()
static s_mtx := hb_mutexCreate()
[...]
hb_mutexLock()
[...]
hb_mutexUnlock()
[...]
return
It should help users in many places. Now it's possible to use as
workaround file wide static variables and INIT procedures but it
does not resolve the problem when some functions can be activated
from other INIT code and makes the final code more complicated then
necessary.
For final user the above modification will mean that hb_mutexCreate()
behaves like other fully optimized functions and can be used for
static variable initialization.
2. CRITICAL FUNCTION|PROCEDURE
I recently wrote about them message to Marek Horodyski and I said that
they do not give any new functionality in comparison to explicit use of
mutexes but I recently rethink the problem and I'm finding two features:
- user cannot forgot about unlocking the mutex because it will be unlocked
by HVM automatically
- HVM will unlock them in all cases also when thread generate exception
like QUIT or BREAK so it's not necessary to use BEGIN SEQUENCE / ALWAYS
statment as protection, f.e. with above modification I can write code
like:
proc p()
static s_mtx := hb_mutexCreate()
hb_mutexLock()
[...do sth...]
hb_mutexUnlock()
return
but if [...do sth...] can generate exception, f.e. RT error then
I should add protection code which will always unlock the mutex:
proc p()
static s_mtx := hb_mutexCreate()
hb_mutexLock()
begin sequence
[...do sth...]
always
hb_mutexUnlock()
endsequence
return
With CRITICAL functions/procedures to reach the same effect it will
be enough to make:
critical proc p()
[...do sth...]
return
Both modifications are similar but they are not fully replaceable so
I want to introduce both.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Viktor, Thanks for your explanation. There're still some things to clarify, if you don't mind. On 29 Oct 2008 at 7:50, Szakáts Viktor wrote: > >> You're again and again trying to add Windows > >> specific features to GTWVT, but such things > >> simply don't belong there. GTWVT is a console > >> emulation, and there is no need for any platform > >> specific whistles and bells there. Rather the main > >> point is that an application written for GTWVT can > >> be ported to GTWIN, GTXWC, GTTRM without > >> modification and with an equivalent feature set. > > > > If GTWVT is restricted to "console emulation only" then I wonder why > > we need to develop > > GTWVT? Why not using GTWIN instead which is a native console? > > Because it has quite some limitations (like > screen size, limited fonts selection) and > a worse "feel". GTWVT feels much more "native > Windows", than GTWIN. It also allows for a > WinMain() app to be built, which could have > other advantages. I see that we are having a "grey area" here. Even your own explanation contradicts with one another: > >> [...] Rather the main > >> point is that an application written for GTWVT can > >> be ported to GTWIN [...] without > >> modification and with an equivalent feature set. but then you said later: > Because it [GTWIN] has quite some limitations (like > screen size, limited fonts selection) [...] Don't you agree here that an application written to use that "special feature" of GTWVT (special screen size, font selection) cannot be ported to GTWIN "without modification with an equivalent feature set"? So, how to determine which enhancements are allowed (eg. special fonts/screen size), and which others are not (eg. window style)? Even gfxPrimitive() is allowed in GTWVT, although there is no equivalent feature in GTWIN. Why? regards, budyanto ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How to retrieve - from PRG to C
On Wed, 29 Oct 2008, Pritpal Bedi wrote:
Hi Pritpal,
> How I can retrieve pGT in c code sent via prg code.
> Local pGT, pGT1
> pGT := hb_gtCreate( 'WVG' )
> pGT1 := hb_gtSelect( pGT )
> hb_gtInfo( HB_GTI_PGT, pGT1 )
> IN GT INFO METHOD
> {
>PHB_GT pGT = hb_itemGetPtr( pInfo->pNewVal );
>// I do not receive pGT pointer. What I am missing ?
> }
hb_itemGetPtr( pInfo->pNewVal ) returns pointer to structure
which holds pGT pointer:
PHB_GT * pGtPtr = ( PHB_GT * ) hb_itemGetPtr( pInfo->pNewVal );
PHB_GT pGT = *pGtPtr;
Anyhow it may change in the future so I cannot promise that
this code will work. I'd prefer to add new function:
PHB_GT hb_gt_ItemBase( PHB_ITEM pItemGT )
which can be used with hb_gt_BaseFree() in the same way as
hb_gt_Base() so your code will not be affected by possible
future modifications in internal pGT representation.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-10-29 18:33 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
2008-10-29 18:33 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbgtcore.h * harbour/source/rtl/hbgtcore.c + added PHB_GT hb_gt_ItemBase( PHB_ITEM pItemGT ) best regards Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
After sending the following message I read Przemek's explanation which answers all my questions. Sorry for the noise... regards, budyanto On 29 Oct 2008 at 23:43, "Harbour Project Main Develop wrote: > Hi Viktor, > > Thanks for your explanation. There're still some things to clarify, if you > don't > mind. > [...] ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MT extensions
Hello Przemek
Przemyslaw Czerpak-2 wrote:
>
> I will want to introduce two extensions for MT mode.
>
> 1. allow to use hb_mutexCreate() as static variable initialization.
>
>If we unblock using hb_mutexCreate() as static variable initializer
>(now we can use only fully optimized functions: static s :=
> HB_BITOR(1,2))
>then the same code can be reduced to:
> proc p()
> static s_mtx := hb_mutexCreate()
> [...]
> hb_mutexLock()
> [...]
> hb_mutexUnlock()
> [...]
> return
>
> 2. CRITICAL FUNCTION|PROCEDURE
>- user cannot forgot about unlocking the mutex because it will be
> unlocked
> by HVM automatically
>- HVM will unlock them in all cases also when thread generate exception
> like QUIT or BREAK so it's not necessary to use BEGIN SEQUENCE /
> ALWAYS
> statment as protection, f.e. with above modification I can write code
> like:
> proc p()
> static s_mtx := hb_mutexCreate()
> hb_mutexLock()
> [...do sth...]
> hb_mutexUnlock()
> return
> but if [...do sth...] can generate exception, f.e. RT error then
> I should add protection code which will always unlock the mutex:
> proc p()
> static s_mtx := hb_mutexCreate()
> hb_mutexLock()
> begin sequence
>[...do sth...]
> always
>hb_mutexUnlock()
> endsequence
> return
> With CRITICAL functions/procedures to reach the same effect it will
> be enough to make:
> critical proc p()
> [...do sth...]
> return
>
> Both modifications are similar but they are not fully replaceable so
> I want to introduce both.
>
Perfect.
CRITICAL PROC p() is the easiest way. Can it be implemented in C also? Like
:
HB_FUNC_CRITICAL( SOMEFUNC )
{
// do sth
}
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/MT-extensions-tp20230982p20233603.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-10-29 12:46 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
2008-10-29 12:46 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED]) * harbour/contrib/gtwvg/gtwvg.c ! Cleaned debug call left by mistake. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/2008-10-29-12%3A46-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp20234420p20234420.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-10-29 18:33 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Thanks Przemek Przemyslaw Czerpak-2 wrote: > > 2008-10-29 18:33 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/include/hbgtcore.h > * harbour/source/rtl/hbgtcore.c > + added PHB_GT hb_gt_ItemBase( PHB_ITEM pItemGT ) > Now I will be able to retieve pGT at C level. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/2008-10-29-18%3A33-UTC%2B0100-Przemyslaw-Czerpak-%28druzus-at-priv.onet.pl%29-tp20232004p20234480.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] MT extensions
On Wed, 29 Oct 2008, Pritpal Bedi wrote:
Hi Pritpal,
> CRITICAL PROC p() is the easiest way.
It depends on context. There are situations where it cannot be used
as mutex replacement - you will end with mutex simulation using
critical function and conditional variable.
> Can it be implemented in C also? Like
> HB_FUNC_CRITICAL( SOMEFUNC )
> {
>// do sth
> }
No. At least in the above way because it cannot work. The protection
has to be external to function body because classic C does not support
any mechanism which allow to bind user code as function preamble/postamble.
Additionally we have to make it working also for pure PCODE functions
loaded from .hrb files or returned directly by our compiler.
It will be possible to mark any Harbour function written in C or as .prg
code as CRITICAL for HVM. So they will have to be registered in HVM as
critical ones.
Please also note that CRITICAL function/procedure does not give
mutual exclusion because it is called CRITICAL. It's necessary
to execute low level C code which initializes mutex and then will
lock and unlock it. Hiding these operations for .prg code gives
some sense for Harbour programmers and can simplify .prg code also
increasing the speed but in C it does not give anything more then
declaring some macros which will replace real function calls what
will not change anything in final binaries and what anyone can do
for his own use at any moment :-)
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hello Przemek <<< And Pritpal wants to remove it and simply inherit from GTWVT. IMHO it's good idea. >>> Exactly. GTWVG is 100%GTWVT + Redirecting few more messages and extending the structure a little bit. GUI calls and elements are totally independant from core GTWVG. So instead of updating GTWVG core whenever there is a change in GTWVT is a pain. There are two possibilities to resolve it: 1) Some mechanism to inherit the GT and add only methods which change the basic behavior. Something like : HB_GTCLASS GTWVG INHERITS GTWVT Method WndProc( m,n,w,l ) Method ProcessMessages( pWVT ) and like. I do not know can this be implemented or not, just a thought. 2) All additions in GTWVG.C and GTWVG.H be inserted in GTWVT.C and GTWVT.H under some define, e.g., #ifdef __GTWVG__. Though first solution will allow GT development scaling to next level. <<< Now the proposed extensions. We already have in GUI based GTs extensions which are not portable to other GTs. F.e. you added font resizing to GTWVT when user changes the window size (just like in GTALLEG). I like this feature but it's not portable to other GTs like GTTRM/GTCRS/GTSLN which have to accept that terminal changes its state without our control and can be resized by user what usually changes number of rows and columns so it's compatible with previous GTWVT behavior. There are some differences between GTs and we cannot hide all of them. >>> You have summed up the whole point of my proposals. Compatibility means the code written is "compilable" with every GT, and not "behavable similarly". You can link tests/wvtext.prg ( targetting pure console output ) with GTWVG without problems. GUI extensions comes into play only when called in the application, not in the core code. <<< In this case we talk about three features: - passing style to console window so it can be tuned to look and behave like other OS windows - bounding console window with other group of visible objects or desktops - setting initial possition for new console window. >>> Plus a few more attributes, all generic. <<< For me all of them are important just like important is font selection or color palette setting. In some situations even much more important because without them it may not be possible to create console window at all in some environments, f.e. in XWindow I can display console window on different desktops, different XServers and different computers. If it will not be possible to control some of such local to given GT features then it may not possible to use some GTs. F.e. I can have application which works on remote server without any display adapter as daemon (service in Windows technology). On request this application can create console window using GTXWC on my local computer giving some functionality like online configuration. If I do not introduce some new features to GTXWC which are not available in MS-Windows/DOS world then GTXWC will not be usable for me. I will have to make copy of GTXWC for my own use to change only few lines just like now GTWVG is copy of GTWVT with some extensions. >>> Absolutely true observation. <<< It's not good situation with also introduce other problems. Extensions will appear locally and will be strictly bound with given GTs so code using them will not be portable ot other GTs and platforms. We should try to reduce such situation and if possible try to define some interface which can be implemented also in other GTs which have similar possibilities. If sth cannot be well emulated by all GTs then we should add option which will allow to check GT capabilities from user code. F.e. just like now we can call hb_gtInfo(HB_GTI_ISGRPAHIC) to check if GT can operate on pixels or only on characters. It does not mean that we need all extensions in core code but we should allow to write 3-rd party / contrib code which can use core GTs as base. >>> IMO if all calls (CUI,GUI,else) are routed via GT core, it is more portable. Let's take an example: Windows resizing is retrieved via HB_K_RESIZE event and is routed in the core. Now appln code if LastKey() == HB_K_RESIZE // if you are in browser navigation loop #if defined(__GTWVG__) .or. defined(__GTWVT__) // Reconfigure browse to reflect to the situation #else // Do nothing #endif endif OR if LastKey() == K_F10 #ifdef __MT__ // Execute a new thread, execute hb_gtReload()/hb_gtCreate() and execute the root function #else // Just call the root function #endif You never have to look back which GT you are using. You have a feature or not can be controlled via a single define. I used this mechanism when working with Xbase++ and Clipper with same sources. <<< In this case I see why Pritpal wants to introduce such extensions and seems that the final results will be very interesting. Anyhow I do not like that they are such strictly hardcoded to be MS-Windows API parameters. In such case we
[Harbour] wince
i compiled wcedemo. when i try to run in on a PocketPc nothing happens. no error, no window opens. Please help. i very eager to unitize Harbour under PocketPC Thanks All of You, Abe -- View this message in context: http://www.nabble.com/wince-tp20236568p20236568.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] wince
On Wed, 29 Oct 2008, Abeb wrote: > i compiled wcedemo. > when i try to run in on a PocketPc nothing happens. no error, no window > opens. > Please help. i very eager to unitize Harbour under PocketPC How did you compile Harbour for WinCE? Used platform, C compiler and build scripts. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] 2008-10-30 00:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu)
2008-10-30 00:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * ChangeLog + Clarification to previous entry. * source/common/hbgete.c * source/common/hbfsapi.c ! Blind fix for OS/2 compiler warnings. David, please test. * source/rtl/philes.c * Minor (0 -> '\0'). * source/compiler/hbusage.c ! Fixed old typo in help text. ; BTW: What is missing for gettext support? -- Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
On Wed, 29 Oct 2008, Pritpal Bedi wrote:
Hi Pritpal,
> You never have to look back which GT you are using. You have a feature or
> not can be
> controlled via a single define. I used this mechanism when working with
> Xbase++ and Clipper
> with same sources.
Conditional compilation does not resolve all problems and in some
situation it may not be enough. We should always try to reduce
and differences when possible.
>HB_GTI_WINDOWSTYLE
>HB_GTI_WINDOWEXSTYLE
Why do you need both?
I know CreateWindowEx() parameters but I'm interesting in
functionality you want to implement so I can try to reproduce
it in GTXWC. I'm not interesting in writing Mini WINE to emulate
MS-Windows API :-)
>HB_GTI_POS_X
>HB_GTI_POS_Y
What is the difference to HB_GTI_SETPOS_XY and why it cannot be used?
>HB_GTI_PARENT
I guess you want to create nested windows and you need parent window
handle. Fine but what protection do you plan to make against destroying
parent window with subwindow active? Can you define some expected
behavior for such situation? What is real MS-window behavior in such
case? Does it destroy all subwindows automatically? What happens if
you will try to use child window handle after closing parent?
I do not know real MS-Win behavior but IMHO such functionality should
be started in parent console window which can send its own handle to
child window registering this child in its own structure so it can be
dealocated automatically when parent window is closed. Otherwise we will
create easy way to create set of dummy/wrong OS handles which may cause
different bad side effects when accessed. GPF is the very optimistic in
such case but there are also possible much worse situations. F.e. in
*nixes all devices use common handle system so you can cause DBF file
corruption if you will write to device closed without your knowledge
and closed handle number was reused by RDD inside USE command exected
later. It may happen with application tested for many month/years by
different users but user#1001 hit [X] in the wrong moment and the
hardly repeated black scenario happened and very important data were
lost.
So it's extremely important to always protect core code against such
situation even if it's very small chance for such spectacular crashes.
Here we will also need at least some basic protection.
> I mean sll these attributes as I outlined before:
> typedef struct
> {
> DWORD dwExStyle,/* 0 */
> DWORD dwStyle, /* WS_THICKFRAME|WS_OVERLAPPED|WS_CAPTION|
>
> WS_SYSMENU|WS_MINIMIZEBOX|WS_MAXIMIZEBOX */
> intx, /* 0 */
> inty, /* 0 */
> intnWidth, /* CW_USEDEFAULT */
> intnHeight, /* CW_USEDEFAULT */
> PHB_GT pGTParent, /* NULL */
> intiCmdShow, /* SW_NORMAL */
> BOOLbDefault, /* TRUE */
> } HB_WVTINIT, * PHB_WVTINIT;
>
> None of the above parameters are Windows Specific. All parameters can be
> exploited
> alsmost in similar way. How a GT take advantage of it depends on its
> capabilities.
The idea is not MS-Windows specific but parameters you requested are
nearly _exactly_ MS-Windows CreateWindowsEx() function parameters.
Would you like to see parameters used by XWindow? In summary they
are much better because in XWindow protocol problems with portability
and remote access and using different hardware and OS on client and
server side are already resolved so we will not have to reinvent the
wheel in few cases. So maybe I'll define them as Harbour standard and
you will try to write emulation layer for MS-Windows ;-)
It's a joke of course but should illustrate the problem when you try
to make sth strictly bound with given OS.
Please also do not forget about yet another functionality. As long as
it will be possible to recreate all application windows from scratch
using only our own meta description then it will be possible to have
GTNET in application running on the server and native GT client on user
side. When user computer crashes then it's enough to connect to the
server again and restore all windows using information from server.
In the moment when you introduce hidden bindings between GT windows
not visible for our GT layer you are loosing such functionality.
It would be very nice if you can develop GTWVG keeping it at least
on very basic level so this GT will be fully functional for remote
access.
> This is ONE most important attributes but attracts few more parameters,
> especially pGTParent.
> Put together GT will be able to create MODAL dialogs, CHILD dialogs, etc,
> list is endless.
See above. Passing OS handles directly does not resolve fully the problem,
is very danger in some cases and can block future extensions. I want to
have such functionality but we cannot add sth like that to core code as is
without defining relations between our own GT window structures and protection
code.
> <<<
> BTW we can ad
Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Przemek
<<<
Conditional compilation does not resolve all problems and in some
situation it may not be enough. We should always try to reduce
and differences when possible.
>>>
ok.
<<<
>HB_GTI_WINDOWSTYLE
>HB_GTI_WINDOWEXSTYLE
Why do you need both?
I know CreateWindowEx() parameters but I'm interesting in
functionality you want to implement so I can try to reproduce
it in GTXWC. I'm not interesting in writing Mini WINE to emulate
MS-Windows API :-)
>>>
Function Main()
do while .t.
nKey := Inkey(0)
if nKey == K_F10
hb_ThreadStart( {|| MyFunc() } )
elseif nKey == K_ESC
exit
endif
enddo
Return NIL
Function MyFunc()
Local pGT, pGT1
pGT := hb_gtCreate( 'WVT' )
SetColor( 'N/W' )
CLS
USE TEST SHARED
// BROWSER CODE
Navigation Loop
if nKey == K_F2
pGT1 := hb_gtCreate( 'WVT' )
hb_gtInfo( HB_GTI_RESIZABLE, .F. )
hb_gtInfo( HB_GTI_WINEXSTYLE, HB_GTSTYLE_MODAL )
hb_gtInfo( HB_GTI_WINSTYLE, HB_GTSTYLE_NOTITLEBAR )
hb_gtInfo( HB_GTI_SIZE, 7, 40 )
hb_gtInfo( HB_GTI_SETPOS_ROWCOL, 10, 10 )
hb_gtInfo( HB_GTI_PARENT, pGT )
SetColor( 'W+/W' )
CLS// I do not want it to be visible
automatically
hb_gtInfo( HB_GTI_SHOWWINDOW ) // so this command
Alert( 'Continue next process?', { 'Yes','No' } )
hb_gtDestroy( pGT1 )
hb_gtSelect( pGT )
endif
What I am trying to achive is to create a modal window pGT1 on top of parent
pGT.
This can be achieved in Windows as:
CreateWindowEx( WS_EX_DLGMODALFRAME,
...,
...,
dwStyle with flag to off titlebar and
sizebox,
x,
y,
width,
height,
hWndParent,
...
...
etc )
x,y,width,height can be adjusted after window is created.
But WS_EX_DLGMODALFRAME is not possible to be assigned afterwards.
To make a window true modal and yet to retain its original windows nature
it has to be CREATED with these flags. It also needs hWndParent.
In next evolution of the GT we may need this functionality, so am I
emphasizing.
My goal is not to introduce Windows constants, we can have our own, but is
to
have slots to achieve the required functionality.
<<<
>HB_GTI_POS_X
>HB_GTI_POS_Y
What is the difference to HB_GTI_SETPOS_XY and why it cannot be used?
>>>
It can be. Right now it just sets the windows coordinates but does not
retain in
structure member. We need to retain it prior to executing CreateWindowEx().
<<<
>HB_GTI_PARENT
I guess you want to create nested windows and you need parent window
handle. Fine but what protection do you plan to make against destroying
parent window with subwindow active? Can you define some expected
behavior for such situation? What is real MS-window behavior in such
case? Does it destroy all subwindows automatically? What happens if
you will try to use child window handle after closing parent?
I do not know real MS-Win behavior but IMHO such functionality should
be started in parent console window which can send its own handle to
child window registering this child in its own structure so it can be
dealocated automatically when parent window is closed. Otherwise we will
create easy way to create set of dummy/wrong OS handles which may cause
different bad side effects when accessed. GPF is the very optimistic in
such case but there are also possible much worse situations. F.e. in
*nixes all devices use common handle system so you can cause DBF file
corruption if you will write to device closed without your knowledge
and closed handle number was reused by RDD inside USE command exected
later. It may happen with application tested for many month/years by
different users but user#1001 hit [X] in the wrong moment and the
hardly repeated black scenario happened and very important data were
lost.
So it's extremely important to always protect core code against such
situation even if it's very small chance for such spectacular crashes.
Here we will also need at least some basic protection.
>>>
I need the parent window handle just to create a modal window. A modal
window
never allows to access its parent any way, that is why it is called modal.
I do not know the window handles detail in other nixes, but in Windows it is
absolutely safe. It is just a handle to a Window returned with
CreateWindowEx()
function and has nothing to do with any other functionality.
You know better about all this stuff, so your judgement is ultimate.
<<<
The idea is not MS-Windows specific but parameters you requested are
nearly _exactly_ MS-Windows CreateWindowsEx() function parame
[Harbour] 2008-10-29 19:06 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED])
2008-10-29 19:06 UTC-0800 Pritpal Bedi ([EMAIL PROTECTED]) * harbour/contrib/gtwvg/gtwvg.c * harbour/contrib/gtwvg/gtwvg.h * harbour/contrib/gtwvg/hbgtwvg.ch + Added the possibility to have transparency on Window. Work-in-progress ! Rearranged .H structure for future seggregations into smaller structures * harbour/contrib/gtwvg/tests/demowvg.prg + Added functionality to make a window transparent. ; : Press F11 and F12 to increase/decrese transparency. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/2008-10-29-19%3A06-UTC-0800-Pritpal-Bedi-%28pritpal%40vouchcac.com%29-tp20239645p20239645.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] 2008-10-28 12:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
Hi Pritpal, Przemek,
> I guess you want to create nested windows and you need parent window
> handle. Fine but what protection do you plan to make against destroying
> parent window with subwindow active? Can you define some expected
> behavior for such situation? What is real MS-window behavior in such
> case? Does it destroy all subwindows automatically? What happens if
> you will try to use child window handle after closing parent?
In the area of window's parent and modality, I'd like to share the convention
in gtwvw as follows.
(I hope it might be usefull in deciding the policy to the general API here.)
/*OpenWindow(row1, col1, row2, col2, ;
*nStyle, nParentWin)
*rowx and colx are relative to MAIN WINDOW (not current window!)
*rowx and colx are used for:
*(1) positioning window to its initial position,
*(2) determining the size of the window
*(3) become the new maxrow() and maxcol() in Standard mode
*(4) saved into RowOfs and ColOfs in MainCoord mode
*
*nStyle is window style
*
*nParentWin is parent window of the new one we're about to open.
* default is: current window (in Standard Mode)
* topmost window (in MainCoord Mode)
* If you want the new window to not have parent,
* pass -1 as nParentWin.
*
*returns window number if successful
*returns 0 if failed
*/
Let's forget about the coordinates for now (our discussion haven't got there
yet).
Further explanation regarding nParentWin is as follows:
nParentWin = 0: the parent is the Main Window
nParentWin = n: the parent is the n-th window
nParentWin = -1: no parent (the window is of the same level as the Main Window,
and it will present in
the taskbar as the Main Window)
When a window is open with a parent, user is not allowed to switch focus to the
parent. (The
subwindow is always on top of the parent.) This is similar to the "modal"
behaviour in Windows, but not
exactly the same.
In gtwvw window must be closed in reversed order: window #n, #n-1, ..., #1
This convention was made because of the limitation of the model (bad design).
IMHO the expected behaviour of closing window is to the deny the close
operation if it has a
subwindow.
Sorry I can only describe what's seen from programmer perspective (the expected
behaviour), since I
don't have technical knowledge to the new GTAPI.
regards,
budyanto
On 29 Oct 2008 at 18:51, Pritpal Bedi wrote:
>
> Przemek
>
> <<<
> Conditional compilation does not resolve all problems and in some
> situation it may not be enough. We should always try to reduce
> and differences when possible.
> >>>
>
> ok.
>
> <<<
> >HB_GTI_WINDOWSTYLE
> >HB_GTI_WINDOWEXSTYLE
>
> Why do you need both?
> I know CreateWindowEx() parameters but I'm interesting in
> functionality you want to implement so I can try to reproduce
> it in GTXWC. I'm not interesting in writing Mini WINE to emulate
> MS-Windows API :-)
> >>>
>
> Function Main()
>
>do while .t.
> nKey := Inkey(0)
>
> if nKey == K_F10
> hb_ThreadStart( {|| MyFunc() } )
>
> elseif nKey == K_ESC
> exit
>
> endif
>enddo
>
>Return NIL
>
> Function MyFunc()
>Local pGT, pGT1
>
>pGT := hb_gtCreate( 'WVT' )
>SetColor( 'N/W' )
>CLS
>
>USE TEST SHARED
>// BROWSER CODE
>Navigation Loop
> if nKey == K_F2
> pGT1 := hb_gtCreate( 'WVT' )
> hb_gtInfo( HB_GTI_RESIZABLE, .F. )
> hb_gtInfo( HB_GTI_WINEXSTYLE, HB_GTSTYLE_MODAL )
> hb_gtInfo( HB_GTI_WINSTYLE, HB_GTSTYLE_NOTITLEBAR )
> hb_gtInfo( HB_GTI_SIZE, 7, 40 )
> hb_gtInfo( HB_GTI_SETPOS_ROWCOL, 10, 10 )
> hb_gtInfo( HB_GTI_PARENT, pGT )
>
> SetColor( 'W+/W' )
> CLS// I do not want it to be visible
> automatically
> hb_gtInfo( HB_GTI_SHOWWINDOW ) // so this command
>
> Alert( 'Continue next process?', { 'Yes','No' } )
>
> hb_gtDestroy( pGT1 )
> hb_gtSelect( pGT )
> endif
>
> What I am trying to achive is to create a modal window pGT1 on top of parent
> pGT. This can be achieved in Windows as:
>
> CreateWindowEx( WS_EX_DLGMODALFRAME,
>...,
>...,
>dwStyle with flag to off titlebar and
> sizebox,
>x,
>y,
>width,
>height,
>hWndParent,
>...
>...
>etc )
>
> x,y,width,height can be adjusted after window is created.
> But WS_EX_DLGMODALFRAME is not possible to be assigned afterwards.
> To make a window true modal and yet to retain its original windows nature
> it has to be CREATED with these flags. It also needs hWndParent.
>
> In next evolution of the
