Re: [Harbour] SF.net SVN: harbour-project:[12768] trunk/harbour
Thanks Pritpal. - Original Message - From: vouch...@users.sourceforge.net To: harbour@harbour-project.org Subject: [Harbour] SF.net SVN: harbour-project:[12768] trunk/harbour Date: Mon, 26 Oct 2009 04:16:30 + Revision: 12768 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12768view=rev Author: vouchcac Date: 2009-10-26 04:16:27 + (Mon, 26 Oct 2009) -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Hi Massimo, I try explain you a possible feature for hbmk2 if in my source is included REQUEST ADS i must add to hbmk2 ace32.lib +rddads.lib REQUEST BMDBFCDX hbbmcdx.lib REQUEST HB_MEMIO hbmemio.lib REQUEST HB_GT_WVG gtwvg.lib REQUEST ADORDD rddado.lib will this intelligence be in hbmk2 ? detect needed library in automatic (not all but best help same user that none) Is possible at least a messages? add hbmemio.lib hbmk2 will never replace thinking from the side of app programmers. harbour user read in prg and not found right information about lib similar problem if my source include #include minigui.ch #include fivewin.ch This would require knowledge of internal details of 3rd party and contrib libs inside hbmk2, which is not good solution (f.e. who will maintain it? I certainly won't. It's BTW impossible if we consider all 3rd party versions and differences between version, etcetc). Instead we could introduce some sort of USING or IMPORT keyword (f.e. as #pragma) plus a compiler parser (like the one for #include) to extract this information, so that hbmk2 can automatically add thos refereed *.hbc files* from .prg source code. .hbc files can in turn pull in all required libs and headers dirs. It's important to deal with .hbc only, and not libs, inc paths and whatnot directly. If we have the infrastructure, it seems relatively easy to add it to hbmk2. [ Note, I don't we should use REQUEST for this purpose, since it works differently. ] Possible hbmk2 be renamed in hbmk? Not until we have hbmk, but as I told in the past, I think hbmk2 stuck enough to be a proper name, it's also much easy to google to, etc. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Destructors of static scope variables
Hi all Is it expected behavior that this program does not output Destructor? #include hbclass.ch static oMSCAL function main() MSCALInit() //oMSCAL := nil return nil procedure MSCalInit() oMSCAL := HActiveX():New() return CLASS HActiveX METHOD New DESTRUCTOR Dtor ENDCLASS METHOD New() CLASS HActiveX return self PROCEDURE Dtor() CLASS HActiveX ? Destructor RETURN If I set oMSCAL to nil it does work of course. Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
2009/10/26 Viktor Szakáts harbour...@syenar.hu Hi Massimo, hbmk2 will never replace thinking from the side of app programmers. Yes you are right but think that we haven't jet good info so maj be a problem for a new user find right information harbour user read in prg and not found right information about lib similar problem if my source include #include minigui.ch #include fivewin.ch This would require knowledge of internal details of 3rd party and contrib libs inside hbmk2, which is not good solution (f.e. who will maintain it? I certainly won't. It's BTW impossible if we consider all 3rd party versions and differences between version, etcetc). Instead we could introduce some sort of USING or IMPORT keyword (f.e. as #pragma) plus a compiler parser (like the one for #include) to extract this information, so that hbmk2 can automatically add thos refereed *.hbc files* from .prg source code. .hbc files can in turn pull in all required libs and headers dirs. It's important to deal with .hbc only, and not libs, inc paths and whatnot directly. If we have the infrastructure, it seems relatively easy to add it to hbmk2. [ Note, I don't we should use REQUEST for this purpose, since it works differently. ] This can be a solution also for prev problem sufficent add in source right pragma directive then is possible compile without know name of library also compiling a source found in internet maj be easy done i can do modification in existing source of tests adding your directive in xbase++ is present a preprocessor directive #pragma library (mylib.lib) i not sure that is same but same body will post xbase++ documentation Possible hbmk2 be renamed in hbmk? Not until we have hbmk, but as I told in the past, I think hbmk2 stuck enough to be a proper name, it's also much easy to google to, etc. ok sorry now i remember -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
hbmk2 will never replace thinking from the side of
app programmers.
Yes you are right
but think that we haven't jet good info so maj be a problem for a new
user find right information
It can't even replace documentation ;)
harbour user read in prg and not found right information about lib
similar problem if my source include
#include minigui.ch
#include fivewin.ch
This would require knowledge of internal details of 3rd
party and contrib libs inside hbmk2, which is not good
solution (f.e. who will maintain it? I certainly won't.
It's BTW impossible if we consider all 3rd party versions
and differences between version, etcetc).
Instead we could introduce some sort of USING or
IMPORT keyword (f.e. as #pragma) plus a compiler
parser (like the one for #include) to extract this
information, so that hbmk2 can automatically add
thos refereed *.hbc files* from .prg source code.
.hbc files can in turn pull in all required libs and
headers dirs.
It's important to deal with .hbc only, and not libs,
inc paths and whatnot directly.
If we have the infrastructure, it seems relatively
easy to add it to hbmk2.
[ Note, I don't we should use REQUEST for this purpose,
since it works differently. ]
This can be a solution also for prev problem
sufficent add in source right pragma directive
then is possible compile without know name of library
also compiling a source found in internet maj be easy done
i can do modification in existing source of tests adding your
directive
in xbase++ is present a preprocessor directive
#pragma library (mylib.lib)
i not sure that is same but same body will post xbase++ documentation
Yes, something like this, but instead of direct
lib names, we should try to use .hbc files, which
is much more flexible. Also, above works probably
on the linker/object level, while my proposed
solution works only in source files and in conjunction
with hbmk2. Pbly not generic enough though, so
we may want to use something like:
#pragma option:hbmk2 mylib.hbc
This could be extracted with harbour -sm with output below:
{option:hbmk2}mylib.hbc
This would allow passing any options to any tools.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
If i undestrand your proposal
The problem of made more simple for a newbies is resolved
The only problem maj be that for minigui,fivewin we need hbc copied in
each directory
possible serch/use a predefined dir for hbc(lib) if not present in
current directory
imo also a lib only maj useful
i also think to a hbmk2 only feature
count on my works for a simple work of rearranging Under your supervision
2009/10/26 Viktor Szakáts harbour...@syenar.hu:
hbmk2 will never replace thinking from the side of
app programmers.
Yes you are right
but think that we haven't jet good info so maj be a problem for a new
user find right information
It can't even replace documentation ;)
harbour user read in prg and not found right information about lib
similar problem if my source include
#include minigui.ch
#include fivewin.ch
This would require knowledge of internal details of 3rd
party and contrib libs inside hbmk2, which is not good
solution (f.e. who will maintain it? I certainly won't.
It's BTW impossible if we consider all 3rd party versions
and differences between version, etcetc).
Instead we could introduce some sort of USING or
IMPORT keyword (f.e. as #pragma) plus a compiler
parser (like the one for #include) to extract this
information, so that hbmk2 can automatically add
thos refereed *.hbc files* from .prg source code.
.hbc files can in turn pull in all required libs and
headers dirs.
It's important to deal with .hbc only, and not libs,
inc paths and whatnot directly.
If we have the infrastructure, it seems relatively
easy to add it to hbmk2.
[ Note, I don't we should use REQUEST for this purpose,
since it works differently. ]
This can be a solution also for prev problem
sufficent add in source right pragma directive
then is possible compile without know name of library
also compiling a source found in internet maj be easy done
i can do modification in existing source of tests adding your directive
in xbase++ is present a preprocessor directive
#pragma library (mylib.lib)
i not sure that is same but same body will post xbase++ documentation
Yes, something like this, but instead of direct
lib names, we should try to use .hbc files, which
is much more flexible. Also, above works probably
on the linker/object level, while my proposed
solution works only in source files and in conjunction
with hbmk2. Pbly not generic enough though, so
we may want to use something like:
#pragma option:hbmk2 mylib.hbc
This could be extracted with harbour -sm with output below:
{option:hbmk2}mylib.hbc
This would allow passing any options to any tools.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12764] trunk/harbour
dru...@users.sourceforge.net wrote: 2009-10-23 18:07 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbwin/axcore.c ! fixed wrongly initialized reference counter in AX control. Now when AX Window is closed and all .prg references to OLE are cleared pSink is released. Thank you very much. I still have questions regarding the behavior of destructors, although I can make my HWGUI application behave properly by manually calling the destructor. See my other mail. Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
The only problem maj be that for minigui,fivewin we need hbc copied in each directory possible serch/use a predefined dir for hbc(lib) if not present in current directory There is a search list (path list) for .hbc files already, so everything inside the addon and contrib dirs will be scanned automatically (given some simple naming rules are followed). It's not hbmk2's responsibility to find where 3rd party libs are installed onto a system, if they cannot be found in standard locations. All we can do is to provide standard means to store these files for easy configuration. imo also a lib only maj useful IMO it will just create confusion and extra support problems on this list. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
is possible have a solution also for harbour contrib If i have undestrand right I nedd an hbp file when use ace32.lib+rddads.lib + hbbmcdx.lib +hbmemio.lib another when use only hbmemio.lib another when use only hbbmcdx.lib ecc ecc Note that is only an example i still prefer separate lib adding for hbmk2 You prefer .lib but you're seeking for a concept which is already implemented and called .hbc. .hbc will take care of setting up all .lib files, include dir and whatnot for a given library (package), so developers don't need to worry about the details. They just have to use headers and functions without any additional settings. If .lib files change, they won't even notice. (like in case of hbqt, where the recent split didn't mean any change in user environment, since the .hbc fully covered the change) [ Even better would be if even headers would be automatically added to .prg files when a given package is being selected. ] Or maybe I lost the track in this thread. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
so will be Possible add standard hbc for each harbour contrib like rddads.hbc for ace32.lib+rddads.lib hbbmcdx.hbc for hbbmcdx.lib hbmemio.hbc for hbmemio.lib so i can add one ore more follow line #pragma option:hbmk2 rddads.hbc #pragma option:hbmk2 hbbmcdx.hbc #pragma option:hbmk2 hbmemio.hbc and if in minigui have made his hbc #pragma option:hbmk2 minigui.hbc Very good and sorry for my bad understanding 2009/10/26 Viktor Szakáts harbour...@syenar.hu: You prefer .lib but you're seeking for a concept which is already implemented and called .hbc. .hbc will take care of setting up all .lib files, include dir and whatnot for a given library (package), so developers don't need to worry about the details. They just have to use headers and functions without any additional settings. If .lib files change, they won't even notice. (like in case of hbqt, where the recent split didn't mean any change in user environment, since the .hbc fully covered the change) [ Even better would be if even headers would be automatically added to .prg files when a given package is being selected. ] Or maybe I lost the track in this thread. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
rddads.hbc for ace32.lib+rddads.lib hbbmcdx.hbc for hbbmcdx.lib hbmemio.hbc for hbmemio.lib All contribs have .hbc files since some months. Plus some popular 3rd party libs also have one hosted in utils/hbmk2/examples since the early days of hbmk2. I've also sent these to lib authors. Some of them added it to their project, some of them weren't giving any feedback (probably they weren't interested). so i can add one ore more follow line #pragma option:hbmk2 rddads.hbc #pragma option:hbmk2 hbbmcdx.hbc #pragma option:hbmk2 hbmemio.hbc and if in minigui have made his hbc #pragma option:hbmk2 minigui.hbc No you can't. This was just some vague plans in my mail, it needs to be developed yet. You can however pass .hbc files (now!) to hbmk2 directly: Instead of this: hbmk2 hello.prg minigui.lib gui.lib dll.lib [...] -gtgui -incpath=C: \minigui\include You can use this: hbmk2 hello.prg hmg.hbc Which seems a lot simpler. [ note: above isn't a working sample, I just used minigui to demonstrate the concept. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Destructors of static scope variables
Hi, Alex Strickland wrote: Is it expected behavior that this program does not output Destructor? ... If I set oMSCAL to nil it does work of course. I've not looked to destructor execution order on exit. But try to change ? Destructor to HB_MEMOWRIT(debug.log, Destructor) It is possible, that GT system is closed at the time destructor is executed. And simple text does not appears on the screen. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Sorry if i not understand right Can i use multiple hbc? hbmk2 hello.prg hmg.hbc rddads.hbc hbmemio.hbc 2009/10/26 Viktor Szakáts harbour...@syenar.hu: All contribs have .hbc files since some months. Plus some popular 3rd party libs also have one hosted in utils/hbmk2/examples since the early days of hbmk2. I've also sent these to lib authors. Some of them added it to their project, some of them weren't giving any feedback (probably they weren't interested). so i can add one ore more follow line #pragma option:hbmk2 rddads.hbc #pragma option:hbmk2 hbbmcdx.hbc #pragma option:hbmk2 hbmemio.hbc and if in minigui have made his hbc #pragma option:hbmk2 minigui.hbc No you can't. This was just some vague plans in my mail, it needs to be developed yet. You can however pass .hbc files (now!) to hbmk2 directly: Instead of this: hbmk2 hello.prg minigui.lib gui.lib dll.lib [...] -gtgui -incpath=C:\minigui\include You can use this: hbmk2 hello.prg hmg.hbc Which seems a lot simpler. [ note: above isn't a working sample, I just used minigui to demonstrate the concept. ] -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] DllLOad under mingw
Hi All, DllLoad seems to be broken under mingw. try contrib\hbwin\tests\TestDll.prg can anybody look into this? Thanks abe -- View this message in context: http://n2.nabble.com/DllLOad-under-mingw-tp3891691p3891691.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] contrib\hbtpathy\telepath.prg
part of function tp_waitfor seems to commented out!? Can i past my modified version? http://n2.nabble.com/file/n3891721/TELEPATH.PRG TELEPATH.PRG -- View this message in context: http://n2.nabble.com/contrib-hbtpathy-telepath-prg-tp3891721p3891721.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbmk2 suggestion
Sorry if i not understand right Can i use multiple hbc? hbmk2 hello.prg hmg.hbc rddads.hbc hbmemio.hbc Yes, of course. [ you may even refer to another .hbc from an .hbc file. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Destructors of static scope variables
On Mon, 26 Oct 2009, Alex Strickland wrote: Hi Is it expected behavior that this program does not output Destructor? #include hbclass.ch static oMSCAL [...] If I set oMSCAL to nil it does work of course. Yes it's expected. Destructors are not executed for when static variables are cleared and it's intentional design decision. Class definition in Harbour are stored in static variables so if we enable destructor execution for static variables the we introduce very serious limitation because at this moment some class may not exists and it's necessary to document that it's illegal to use any code which may create new object inside destructors. Such situation is now in xHarbour and I can only guess that author never thought what he really does. To enable destructors for static variables we should 1-st change our class code to protect class objects against releasing before destructors are executed. Maybe I'll make it in the future. Now it's documented behavior that at HVM quit state PRG destructors are disabled just before releasing static variables so programmer does not have to worry that application may crash if he activates OOP code for class released before. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBQT - Nearly lost how to implement new GC
On Sat, 24 Oct 2009, Pritpal Bedi wrote:
Hi,
There is a slight change as follows and it works.
This is not a proper change so show me what is the
proper code skeleton.
QWidget * hbqt_par_QWidget( int iParam )
{
QPointer QWidget * pObj;
QWidget * obj = NULL;
pObj = ( QPointer QWidget * ) hb_parptrGC( s_gcQWidget, iParam );
if( pObj == NULL )
{
/* Not a QWidget pointer item, check all registered
* descendant classes
*/
QT_PARAM_INFO * paramInfo = s_paramList;
while( paramInfo )
{
/ This is the change
// hbqt_par_Q*() functions are returning pure object without
QPointer cast. //
obj = ( QWidget * ) paramInfo-pFunc( iParam );
if( obj )
return obj;
Exactly. Sorry it was my typo. I haven't tested above code and I've wrote it
only for this message. Now I see that it needs also yet another modification.
We need parameter to enable/disable RTE in this function. So final version
should look like:
typedef void * ( * QT_PARAM_FUNC ) ( int, BOOL );
[...]
QPageSetupDialog * hbqt_par_QPageSetupDialog( int iParam, BOOL fError )
{
QPointer QPageSetupDialog * pObj;
QPageSetupDialog * obj = NULL;
pObj = ( QPointer QPageSetupDialog * )
hb_parptrGC( s_gcQPageSetupDialog, iParam );
if( pObj == NULL )
{
/* Not a QPageSetupDialog pointer item, check all registered
* descendant classes
*/
QT_PARAM_INFO * paramInfo = s_paramList;
while( paramInfo )
{
obj = ( QPageSetupDialog * ) paramInfo-pFunc( iParam, FALSE );
if( obj )
return obj;
paramInfo = paramInfo-pNext;
}
}
if( pObj == NULL )
{
if( fError )
{
/* RT ERROR - wrong parameter */
}
}
else
{
obj = * pObj;
if( obj == NULL fError )
{
/* RT ERROR - object deleted by other code */
}
}
return obj;
}
If you want then instead of adding new parameter you can define that
iParam 0 disables RTE and change this function to:
QPageSetupDialog * hbqt_par_QPageSetupDialog( int iParam )
{
QPointer QPageSetupDialog * pObj;
QPageSetupDialog * obj = NULL;
BOOL fError = TRUE;
if( iParam 0 )
{
fError = TRUE;
iParam = -iParam;
}
pObj = ( QPointer QPageSetupDialog * )
hb_parptrGC( s_gcQPageSetupDialog, iParam );
if( pObj == NULL )
{
/* Not a QPageSetupDialog pointer item, check all registered
* descendant classes
*/
QT_PARAM_INFO * paramInfo = s_paramList;
while( paramInfo )
{
obj = ( QPageSetupDialog * ) paramInfo-pFunc( -iParam );
if( obj )
return obj;
paramInfo = paramInfo-pNext;
}
}
if( pObj == NULL )
{
if( fError )
{
/* RT ERROR - wrong parameter */
}
}
else
{
obj = * pObj;
if( obj == NULL fError )
{
/* RT ERROR - object deleted by other code */
}
}
return obj;
}
though maybe such version is less readable.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] DllLOad under mingw
Probably something wrong slipped into latest UNICODE modifications. I'd still like to ask others to review my code. I can spot one possible error, but it doesn't fix the problem. (dll tests work in UNICODE mode, only non-UNICODE seems to be affected) Brgds, Viktor On 2009 Oct 26, at 13:27, AbeB wrote: Hi All, DllLoad seems to be broken under mingw. try contrib\hbwin\tests\TestDll.prg can anybody look into this? Thanks abe -- View this message in context: http://n2.nabble.com/DllLOad-under-mingw-tp3891691p3891691.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12769] trunk/harbour
Revision: 12769 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12769view=rev Author: vszakats Date: 2009-10-26 13:19:53 + (Mon, 26 Oct 2009) Log Message: --- 2009-10-26 14:18 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * src/vm/maindllp.c ! Using hb_getProcAddress() instead of GetProcAddress(). Idea submitted to the list, I didn't make any tests, so review it and change it as needed. * contrib/xhb/hbcompat.ch + Added HB_GTI_CLIPBOARDPAST related stuff. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/hbcompat.ch trunk/harbour/src/vm/maindllp.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12770] trunk/harbour
Revision: 12770 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12770view=rev Author: druzus Date: 2009-10-26 14:29:12 + (Mon, 26 Oct 2009) Log Message: --- 2009-10-26 15:29 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbqt/qtcore/QLocale.cpp * harbour/contrib/hbqt/qtcore/QByteArray.cpp ! fixed casting for 64bit builds - in all 64bit builds except Win64 LONG is 64bit integer and HB_LONG is declared as LONG not LONGLONG * harbour/contrib/hbwin/win_dll.c % minor optimization * removed unnecessary casting Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/qtcore/QByteArray.cpp trunk/harbour/contrib/hbqt/qtcore/QLocale.cpp trunk/harbour/contrib/hbwin/win_dll.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12770] trunk/harbour
* harbour/contrib/hbwin/win_dll.c % minor optimization * removed unnecessary casting Thanks a lot. The GPFs is still there so I suspect it has to do with some other factors. BTW, do you see any reason why XPP_DLLEXEC-cDLL variable needs to be kept at all? It would seem to me this can just be deleted. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12771] trunk/harbour
Revision: 12771 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12771view=rev Author: vouchcac Date: 2009-10-26 15:22:06 + (Mon, 26 Oct 2009) Log Message: --- 2009-10-26 08:20 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/generator/hbqtgen.prg ! Fixed to honor Przemek's changes pertaining LONG is 64bit integer and HB_LONG is declared as LONG not LONGLONG Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/generator/hbqtgen.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12764] trunk/harbour
dru...@users.sourceforge.net wrote:
Log Message:
---
2009-10-23 18:07 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbwin/axcore.c
! fixed wrongly initialized reference counter in AX control.
Now when AX Window is closed and all .prg references to OLE
are cleared pSink is released.
With this code, I do not see the destructor being activated:
#include hbgtinfo.ch
#include hbclass.ch
REQUEST HB_GT_WVT_DEFAULT
#define WS_CHILD1073741824
#define WS_VISIBLE 268435456
#define WS_CLIPCHILDREN 33554432
PROCEDURE Main()
LOCAL oMSCAL
WAIT Make sure we are 'Active Window'
oMSCAL := HActiveX():Init( WAPI_GetActiveWindow(), www.google.com, 0, 0,
300, 300 )
WAIT Press any key to exit
RETURN
CLASS HActiveX
DATA oOLE
METHOD Init
METHOD Event
ERROR HANDLER OnError
DESTRUCTOR Dtor
ENDCLASS
METHOD Init( hWnd, cProgId, nTop, nLeft, nWidth, nHeight, cID ) CLASS HActiveX
LOCAL nStyle := WS_CHILD + WS_VISIBLE + WS_CLIPCHILDREN
win_AxInit()
hWnd := WAPI_CreateWindowEX( 0, AtlAxWin, cProgId, nStyle, nLeft, nTop,
nWidth, nHeight, hWnd, 0 )
//::oOLE := WIN_AxGetControl( hWnd, { | event, ... | Event( event, ... ) },
cID )
::oOLE := WIN_AxGetControl( hWnd, { | event, ... | ::Event( event, ... ) },
cID )
RETURN self
PROCEDURE Event( ... ) CLASS HActiveX
LOCAL cEvents :=
LOCAL aEvents := { ... }
aEval( aEvents, { | xEvent | cEvents += HB_ValToStr( xEvent ) + , } )
wapi_OutputDebugString( cEvents )
RETURN
METHOD OnError() CLASS HActiveX
RETURN HB_ExecFromArray( ::oOLE, __GetMessage(), HB_AParams() )
METHOD Dtor() CLASS HActiveX
wapi_OutputDebugString( Dtor )
::oOLE := NIL
wapi_OutputDebugString( After Dtor )
RETURN NIL
STATIC PROCEDURE Event( ... )
LOCAL cEvents :=
LOCAL aEvents := { ... }
aEval( aEvents, { | xEvent | cEvents += HB_ValToStr( xEvent ) + , } )
wapi_OutputDebugString( cEvents )
RETURN
My understanding of the new garbage collection, was that it should work?
If MSCAL.Calender is substituted it GPF's.
Using the procedure instead of the method procedure works fine, the destructor
is called, and no GPF, and the object need not be explicitly set to NIL.
Regards
Alex
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: qtcore4.lib
For compiler mingwin the file hb-mkimp.bat I found this is lines if %HB_COMPILER% == mingw (... ... if exist %HB_DIR_QT%\lib\libQtCore4.a copy /b /y %HB_DIR_QT%\lib\libQtCore4.a %HB_LIB_INSTALL%\libQtCore4.a if exist %HB_DIR_QT%\lib\libQtGui4.acopy /b /y %HB_DIR_QT%\lib\libQtGui4.a%HB_LIB_INSTALL%\libQtGui4.a if exist %HB_DIR_QT%\lib\libQtNetwork4.acopy /b /y %HB_DIR_QT%\lib\libQtNetwork4.a%HB_LIB_INSTALL%\libQtNetwork4.a if exist %HB_DIR_QT%\lib\libQtWebKit4.a copy /b /y %HB_DIR_QT%\lib\libQtWebKit4.a %HB_LIB_INSTALL%\libQtWebKit4.a ---8 And to MSVC or BCC what is needed ? Maybe tutor for making HBQT libs step by step. Best regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: qtcore4.lib
BCC Is not supported AFAIK bcc have low support from qt 2009/10/26 Itamar Lins itamarl...@gmail.com: And to MSVC or BCC what is needed ? Maybe tutor for making HBQT libs step by step. -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: qtcore4.lib
if exist %HB_DIR_QT%\lib\libQtCore4.a copy /b /y %HB_DIR_QT%\lib\libQtCore4.a %HB_LIB_INSTALL% \libQtCore4.a if exist %HB_DIR_QT%\lib\libQtGui4.acopy /b /y %HB_DIR_QT%\lib\libQtGui4.a%HB_LIB_INSTALL% \libQtGui4.a if exist %HB_DIR_QT%\lib\libQtNetwork4.acopy /b /y %HB_DIR_QT%\lib\libQtNetwork4.a%HB_LIB_INSTALL% \libQtNetwork4.a if exist %HB_DIR_QT%\lib\libQtWebKit4.a copy /b /y %HB_DIR_QT%\lib\libQtWebKit4.a %HB_LIB_INSTALL% \libQtWebKit4.a ---8 And to MSVC or BCC what is needed ? For MSVC there is no way to create libs from dlls. In this case the only choice is to build MSVC QT libs from source. Same applies for BCC, but in this case I didn't try to build it manually, but I wouldn't be terribly surprised if it didn't work. Better would be to forget BCC for any serious jobs. Maybe tutor for making HBQT libs step by step. Making HBQT is quite straightforward and covered in INSTALL. If you mean QT, it's not Harbour's job to document it, but you'll find great step by step guide on QT website. Someone even posted a link, it's somewhere in the archives. Maybe someone has it at hand to repost it. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: qtcore4.lib
Viktor Szakáts escreveu: Better would be to forget BCC for any serious jobs. Ok, BCC was abandoned for me. Maybe tutor for making HBQT libs step by step. Making HBQT is quite straightforward and covered in INSTALL. If you mean QT, it's not Harbour's job to document it, but you'll find great step by step guide on QT website. Someone even posted a link, it's somewhere in the archives. Maybe someone has it at hand to repost it. I found this is link http://da-crystal.net/GCMS/blog/qt-windows-amp-vc-2008-express-part1/ But the problem is time of creation. now run 'nmake command , to compile the source ( it will take long time , 1 hour - 4 hours) : * C:\QtSource nmake Best regards, Itamar M Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12764] trunk/harbour
On Mon, 26 Oct 2009, Alex Strickland wrote:
Log Message:
---
2009-10-23 18:07 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbwin/axcore.c
! fixed wrongly initialized reference counter in AX control.
Now when AX Window is closed and all .prg references to OLE
are cleared pSink is released.
With this code, I do not see the destructor being activated:
#include hbgtinfo.ch
#include hbclass.ch
REQUEST HB_GT_WVT_DEFAULT
#define WS_CHILD1073741824
#define WS_VISIBLE 268435456
#define WS_CLIPCHILDREN 33554432
PROCEDURE Main()
LOCAL oMSCAL
WAIT Make sure we are 'Active Window'
oMSCAL := HActiveX():Init( WAPI_GetActiveWindow(), www.google.com, 0, 0,
300, 300 )
WAIT Press any key to exit
RETURN
CLASS HActiveX
DATA oOLE
METHOD Init
METHOD Event
ERROR HANDLER OnError
DESTRUCTOR Dtor
ENDCLASS
METHOD Init( hWnd, cProgId, nTop, nLeft, nWidth, nHeight, cID ) CLASS HActiveX
LOCAL nStyle := WS_CHILD + WS_VISIBLE + WS_CLIPCHILDREN
win_AxInit()
hWnd := WAPI_CreateWindowEX( 0, AtlAxWin, cProgId, nStyle,
nLeft, nTop, nWidth, nHeight, hWnd, 0 )
//::oOLE := WIN_AxGetControl( hWnd, { | event, ... | Event(
event, ... ) }, cID )
::oOLE := WIN_AxGetControl( hWnd, { | event, ... | ::Event(
event, ... ) }, cID )
RETURN self
You are creating new window and you do not store hWnd so this window is
never closed. Classic resource leak. It also means that AX control for
this window isn't freed. Add to HActiveX class
DATA hWnd
and in this function store new window handler in ::hWnd.
PROCEDURE Event( ... ) CLASS HActiveX
LOCAL cEvents :=
LOCAL aEvents := { ... }
aEval( aEvents, { | xEvent | cEvents += HB_ValToStr( xEvent ) + , } )
wapi_OutputDebugString( cEvents )
RETURN
METHOD OnError() CLASS HActiveX
RETURN HB_ExecFromArray( ::oOLE, __GetMessage(), HB_AParams() )
METHOD Dtor() CLASS HActiveX
wapi_OutputDebugString( Dtor )
::oOLE := NIL
Add here:
WAPI_DestroyWindow( ::hWnd )
wapi_OutputDebugString( After Dtor )
RETURN NIL
STATIC PROCEDURE Event( ... )
LOCAL cEvents :=
LOCAL aEvents := { ... }
aEval( aEvents, { | xEvent | cEvents += HB_ValToStr( xEvent ) + , } )
wapi_OutputDebugString( cEvents )
RETURN
My understanding of the new garbage collection, was that it should work?
No. So far no one defined when call back should be deactivated and added
code which will implement such definition. New GC functionality is not used
with our AX code.
If MSCAL.Calender is substituted it GPF's.
Yes it is.
Using the procedure instead of the method procedure works fine, the
destructor is called, and no GPF, and the object need not be
explicitly set to NIL.
It's not fully cleared because your code does not close hWnd so callback
codeblock is never freed. Please recompile Harbour with HB_FM_STATISTIC
(it should work correctly with current SVN) and you will see memory leak
report. If you add:
WAPI_DestroyWindow( ::hWnd )
then it will resolve the problem and you can try to think about automatic
GC activation. When it should be activated? Should we bound it with oOLE
or maybe we should store window handler in GC item and bound callback
destructor with this item so it will be activated when you make:
hWnd := NIL
In such case it will not be necessary to explicitly execute
WAPI_DestroyWindow() because it will execute automatically by
hWnd destructor.
I'm not a windows programmer so I do not want to decide what is
the best choice though I can implement it if you can precisely
define what you need.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: qtcore4.lib
Bcc non seem supported as compiler by qt http://doc.trolltech.com/4.5/compiler-notes.html 2009/10/26 Itamar Lins itamarl...@gmail.com: Viktor Szakáts escreveu: Better would be to forget BCC for any serious jobs. Ok, BCC was abandoned for me. -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12770] trunk/harbour
As per gdb, the crash is somewhere in DllExec(). Brgds, Viktor On 2009 Oct 26, at 16:01, Viktor Szakáts wrote: * harbour/contrib/hbwin/win_dll.c % minor optimization * removed unnecessary casting Thanks a lot. The GPFs is still there so I suspect it has to do with some other factors. BTW, do you see any reason why XPP_DLLEXEC-cDLL variable needs to be kept at all? It would seem to me this can just be deleted. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12772] trunk/harbour
Revision: 12772 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12772view=rev Author: druzus Date: 2009-10-26 19:17:34 + (Mon, 26 Oct 2009) Log Message: --- 2009-10-26 20:17 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/garbage.c ! fixed hb_gcGripDrop() to work well with unlocked items and items freed by GC * harbour/tests/speedtst.prg ! typo in comment Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/src/vm/garbage.c trunk/harbour/tests/speedtst.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[12773] trunk/harbour
Revision: 12773 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12773view=rev Author: druzus Date: 2009-10-26 23:01:50 + (Mon, 26 Oct 2009) Log Message: --- 2009-10-27 00:01 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/vm/hashes.c ! use hb_gcMark() instead of hb_gcItemRef() to mark unlocked item * harbour/src/vm/garbage.c * moved hb_itemClear() from hb_gcGripDrop() to hb_gcGripRelease() Now items are freed in the same way as any other GC blocks and hb_gcGripDrop() is simple wrapper to hb_gcRefFree() * harbour/src/vm/hvm.c * harbour/src/vm/thread.c ! unlock item which stores thread return value to eliminate possible memory leaks, i.e. when thread returns its own pointer item. ! unlock item which stores notify messages to eliminate possible memory leaks, i.e. when mutex is used as notify value in its own message queue. * harbour/include/hbapigt.h * harbour/include/hbgtcore.h * harbour/src/rtl/hbgtcore.c * harbour/src/vm/garbage.c + added new GT method MARK() executed by GC to mark all internall GC blocks as used. + added hb_gtIsGtRef() internal function ! unlock internal GT items (pCargo, pNotifierBlock, pMutex) to eliminate possible memory leaks, i.e. when pGT item is stored in it's own cargo value or is accessed from notifier codeblock Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbapigt.h trunk/harbour/include/hbgtcore.h trunk/harbour/src/rtl/hbgtcore.c trunk/harbour/src/vm/garbage.c trunk/harbour/src/vm/hashes.c trunk/harbour/src/vm/hvm.c trunk/harbour/src/vm/thread.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] to Giancarlo Niccolai regarding inet.txt
Massimo Belgrano wrote: Hi April Can you help me about How can use hbdoc2 running hbmk2 hbdoc2 Generating C source output to 'hbdoc2.c'... Done. hbdoc2.o:hbdoc2.c:(.data+0x438): undefined reference to `HB_FUN_SHOWTEMPLATESHEL P' Compile with the .hbp file hbmk2 hbdoc2.hbp Is possible generate unique file as destination (pdf)? I'm not sure what you mean? The program is still a work in progress, PDF files have not been handled yet. text, ascii, xml, html, and html2 should be in the svn release. The html and html2 files have not links yet, I'm working on that in my local version. April -- Honk if you love peace and quiet. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
