[Harbour] Re: pritpal can you include cp852 encoding in hbide?
Apolinar wrote: As in subject Is not it one from the list hbIDE implements ? Try all. If not, then I have no clue how it can be implemented. I can do only if Qt provides one. Because I do now know the basics so cannot write a sub-class. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/pritpal-can-you-include-cp852-encoding-in-hbide-tp5076269p5076582.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: pritpal can you include cp852 encoding in hbide?
Understood, I'll try to find out something. If I find something I'll report. Regards Apolinar ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Pritpal, I now think that in prg classes we should add destructor and destroy all the children at harbour level from there, so doing that ourself and not leaving the job to Qt The other test I want to do is to use object.deleteLater() but it is not a solution, is an hack ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Pritpal and Vikto, please test this generator
Przemysław Czerpak wrote: You may need explicit destructors in .prg code only if you plan to keep some structures which are not released automatically in harbour object. If you correctly implement releasing all QT objects by automatic GC pointer item destructors then you will not need any PRG level destructors to replicate the same job. Instead of all the protections in hbQT's GC pointer items destruction we are still unable to grasp a logic why for some variables behavior is indifferent. I mean we are never sure which another child is destroyed by Qt with its parent and prevent the latter not to be sent to GC engine. BTW the only one thing which should be introduced yet is an option to mark GC pointer items as attached to other QT structures so they should not be released automatically with the HVM item because they will be released with parent object. Few days before I had resuested for this feature, though I admit, I could not explain that in as simple language as above of your paragraph. If possible, please do it. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4907702.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Pritpal and Vikto, please test this generator
Bisz István wrote:
BTW the only one thing which should be introduced yet is an option to
mark GC pointer items as attached to other QT structures so they should
not be released automatically with the HVM item because they will be
released with parent object.
Yes, indeed, this is the solution for the so hunted GPF-s in HBQT.
In the attachment is the hbqt patch for the hbide crashes in different
circumstances.
The problem is generated by the following sequences in searchreplace.uic:
horizontalSpacer = new QSpacerItem(40, 20, QSizePolicy::Expanding,
QSizePolicy::Minimum);
horizontalLayout-addItem(horizontalSpacer);
and
horizontalSpacer_2 = new QSpacerItem(40, 20,
QSizePolicy::Expanding, QSizePolicy::Minimum);
horizontalLayout_2-addItem(horizontalSpacer_2);
The QSpacerItem is not in inherited from QObject and in this way Qt has no
information about the deletion of the object executed by hbqt. After
deletion of the QSpacerItem by hbqt the subsequent delete of the
horizontalLayout or horizontalLayout_2 generates in Qt engine the deletion
of the child object, in our case the already deleted QSpacerItem...crash.
The attachment contains:
a. QLayout.cpp the generated cpp file.
b. QLayout.qth with the modified QT_QLAYOUT_ADDITEM:
CODE
...
HB_FUNC( QT_QLAYOUT_ADDITEM )
{
QGC_POINTER * p;
QGC_POINTER * q;
HB_TRACE( HB_TR_DEBUG, ( Entering function QT_QLAYOUT_ADDITEM() ) );
q = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 2 );
if( p p-ph q q-ph )
{
HB_TRACE( HB_TR_DEBUG, ( QT_QLAYOUT_ADDITEM() Qt oject: %p is
attached to: %p, p-ph, q-ph ) );
p-bNew = HB_FALSE;
}
hbqt_par_QLayout( 1 )-addItem( hbqt_par_QLayoutItem( 2 ) );
}
...
/CODE
c. THbQtUI.prg with the corrected sequence:
...
HB_TRACE( HB_TR_ALWAYS, 101 )
::oWidget:close()
HB_TRACE( HB_TR_ALWAYS, 102 )
::oWidget := NIL
HB_TRACE( HB_TR_ALWAYS, 103 )
hbide_justACall( i )
RETURN NIL
...
Welcome back, we really missed you.
Though above solution is exactly what effectively handles the
situation, and you have well described it, it is not the only part
where it may fail. Such scenarios can be many, especially when
we are handelling .uic files at the prg level. Also it requires a
manual update of such methods on .qth levels, which in
my opinion is not the right solution.
Przemek's second option is to introduce GC items dependant on
some other is the right direction to go.
-
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4907776.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Pritpal and Vikto, please test this generator
Bisz István wrote: Yes, indeed, this is the solution for the so hunted GPF-s in HBQT. In the attachment is the hbqt patch for the hbide crashes in different circumstances. The problem is generated by the following sequences in searchreplace.uic: horizontalSpacer = new QSpacerItem(40, 20, QSizePolicy::Expanding, QSizePolicy::Minimum); horizontalLayout-addItem(horizontalSpacer); and horizontalSpacer_2 = new QSpacerItem(40, 20, QSizePolicy::Expanding, QSizePolicy::Minimum); horizontalLayout_2-addItem(horizontalSpacer_2); For now I am including above patch in my tests. And if it resolves crashes with the updated code, I will commit. Later we will be waiting for Przemek's commit to see it the same is done on GC levels. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4907848.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi Pritpal, For now I am including above patch in my tests. And if it resolves crashes with the updated code, I will commit. Later we will be waiting for Przemek's commit to see it the same is done on GC levels. OK, sounds good. In any case if it fits to our needs is better than nothing temporarily. It's sufficient to solve the scenario just for the linked non QObject-s. In the future we should switch the QPointer-s to QWeakPointer-s, covering in this way probably the non QObject-s too, but this looks to be a long way. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Pritpal and Vikto, please test this generator
Bisz István wrote:
HB_FUNC( QT_QLAYOUT_ADDITEM )
{
QGC_POINTER * p;
QGC_POINTER * q;
HB_TRACE( HB_TR_DEBUG, ( Entering function QT_QLAYOUT_ADDITEM() ) );
q = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 2 );
if( p p-ph q q-ph )
{
HB_TRACE( HB_TR_DEBUG, ( QT_QLAYOUT_ADDITEM() Qt oject: %p is
attached to: %p, p-ph, q-ph ) );
p-bNew = HB_FALSE;
}
hbqt_par_QLayout( 1 )-addItem( hbqt_par_QLayoutItem( 2 ) );
}
...
/CODE
c. THbQtUI.prg with the corrected sequence:
...
HB_TRACE( HB_TR_ALWAYS, 101 )
::oWidget:close()
HB_TRACE( HB_TR_ALWAYS, 102 )
::oWidget := NIL
HB_TRACE( HB_TR_ALWAYS, 103 )
hbide_justACall( i )
RETURN NIL
...
Did you test this code ? I think, yes.
Then prg level :addItem() method is missing, how you solved that?
Manually writing in TQLayout.prg ?
-
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4908219.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Did you test this code ? I think, yes. Then prg level :addItem() method is missing, how you solved that? Manually writing in TQLayout.prg ? I have this function in TQLayout.prg ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi Pritpal, Did you test this code ? I think, yes. Yes, you are right, and the crash is gone on my Fedora12. Then prg level :addItem() method is missing, how you solved that? Manually writing in TQLayout.prg ? I replaced just QLayout.cpp. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi to everybody, I tried to solve the problem starting from the end, the delete... I wanted to intercept the delete and from the pointer going back to the harbour QGC_POINTER and nullify it From the end you cover all cases in a generic way.. Your solution is from another point of view, you disable the delete statement when GC destructor is called on children so the only way to REALLY destroy a child is to wait for parent deletion... this may solve some problems but, as said and as I understood your sample, we may have deveral hanging objects... Is it also necessary to implement the same logic for addWidget, but also a inverted logic for removeWidget and removeItem... More, we need to devise a standard way to generate such code from qth/include files from the actual generator I think it is very difficult, we should create an in-memory structure of calls and then generate code as automatically as possible... Anyway, congratulations for the finding... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Hi Francesco, More, we need to devise a standard way to generate such code from qth/include files from the actual generator I think it is very difficult, we should create an in-memory structure of calls and then generate code as automatically as possible... Yes, you are right, this patch is just the first step in the crash hunting. The next steps should be oriented to a more general dynamic approach. Best regards, István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Yes, you are right, this patch is just the first step in the crash hunting. The next steps should be oriented to a more general dynamic approach. This is an important patch because it started a new way for solving GPF... Now there are several protections against GPFs... - guarded pointers for objects deriving from QObject - your way when objects are parented at runtime - second parameter of *_gcAllocate_* set to false Still missing is full check on parameter types but Przemek already gave some ideas... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Istvan, in hbide.prg please comment all the :destroy() lines, there are a bunch together... I will try later... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Sorry Pritpal, you were correct. In the QLayout.qth file proposed by Istvan the line of addItem is commented and so the harbour class is not generated... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
A bit more tracing in the debug log
diff -r 020effeac192 harbour/contrib/hbqt/generatorF/hbqtgen.prg
--- a/harbour/contrib/hbqt/generatorF/hbqtgen.prg Thu Apr 15
09:56:57 2010 +0200
+++ b/harbour/contrib/hbqt/generatorF/hbqtgen.prg Thu Apr 15
22:52:42 2010 +0200
@@ -50,6 +50,8 @@
*
*/
/*--*/
+
+#define TRACE_QT_CALLS
#include common.ch
#include fileio.ch
@@ -1237,7 +1239,9 @@
aadd( txt_, + cWidget + iif( lList, void *, ) + * p; )
aadd( txt_, )
aadd( txt_,p = hbqt_par_ + cWidget + ( 1 ); )
-
+#ifdef TRACE_QT_CALLS
+ aadd( txt_, 'HB_TRACE( ' + s_trMode + ', (' +
upper( cWidget ) + '_' + upper( cHBFunc) + ' ) );')
+#endif
/* Insert parameters by reference */
IF ! empty( aPre )
FOR n := 1 TO len( aPre )
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Francesco, Since I'm trying to implement your changes in the generator, if you have a better version please send... My post doesn't contain any other info. I am happy if you can find the solution in the generator part. István ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Since I got GPF in another point (removing the :destroy() part) of the code (releasing a QToolBar) I used the trace above to see what function calls were done on that QToolBar... they are addAction toggleViewAction setIcon at least one of them must have the change you proposed Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] Re: Pritpal and Vikto, please test this generator
Since I got GPF in another point (removing the :destroy() part) of the code (releasing a QToolBar) I used the trace above to see what function calls were done on that QToolBar... they are addAction toggleViewAction setIcon at least one of them must have the change you proposed My experience is that the Qt objects should be released by a controlled pointer zeroing in the prg level, otherwise we are facing to GPF-s (not analyzed harbour internals...). ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
Ok, just for trying to understand how it is possible to proceed and to
validate the idea I did some tests... I was able to remove a GPFs
changing some add* functions.
It was a manual work and I strongly believe it can't be done manually !
Just for reference I post here one of this changed functions, for code review:
HB_FUNC( QT_QMAINWINDOW_ADDTOOLBAR )
{
QGC_POINTER_QMainWindow * q;
QGC_POINTER * p;
HB_TRACE( HB_TR_DEBUG, (QMAINWINDOW_ADDTOOLBAR ) );
q = ( QGC_POINTER_QMainWindow * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 3 );
if ( p p-ph q q-ph )
{
HB_TRACE( HB_TR_DEBUG, ( QT_QMAINWINDOW_ADDTOOLBAR() Qt oject:
%p is attached to: %p, (void *) p-ph, (void *) q-ph) );
p-bNew = HB_FALSE;
if ( q q-ph )
( q-ph )-addToolBar( ( Qt::ToolBarArea ) hb_parni( 2 ), ( (
QToolBar *) p-ph ));
else
HB_TRACE( HB_TR_DEBUG, ( F=QT_QMAINWINDOW_ADDACTION FP=( q-ph
)-addAction( xx ); q-ph is NULL ));
}
}
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Pritpal and Vikto, please test this generator
francesco perillo wrote:
Ok, just for trying to understand how it is possible to proceed and to
validate the idea I did some tests... I was able to remove a GPFs
changing some add* functions.
It was a manual work and I strongly believe it can't be done manually !
Just for reference I post here one of this changed functions, for code
review:
HB_FUNC( QT_QMAINWINDOW_ADDTOOLBAR )
{
QGC_POINTER_QMainWindow * q;
QGC_POINTER * p;
HB_TRACE( HB_TR_DEBUG, (QMAINWINDOW_ADDTOOLBAR ) );
q = ( QGC_POINTER_QMainWindow * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 3 );
if ( p p-ph q q-ph )
{
HB_TRACE( HB_TR_DEBUG, ( QT_QMAINWINDOW_ADDTOOLBAR() Qt oject:
%p is attached to: %p, (void *) p-ph, (void *) q-ph) );
p-bNew = HB_FALSE;
if ( q q-ph )
( q-ph )-addToolBar( ( Qt::ToolBarArea ) hb_parni( 2 ), ( (
QToolBar *) p-ph ));
else
HB_TRACE( HB_TR_DEBUG, ( F=QT_QMAINWINDOW_ADDACTION FP=( q-ph
)-addAction( xx ); q-ph is NULL ));
}
}
If we go this way, i.e., manually changing the code, then
probably we can never finish, nor anybody will take interest in.
There can be thousands of combinations like this.
We should wait until Przemek commits detachable GC pointers.
-
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4910638.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Pritpal and Vikto, please test this generator
francesco perillo wrote:
I continued to do some work on the generator and implemented the check
on -calls
From:
HB_FUNC( QT_QAPPLICATION_CURSORFLASHTIME )
{
hb_retni( hbqt_par_QApplication( 1 )-cursorFlashTime() );
}
To:
HB_FUNC( QT_QAPPLICATION_CURSORFLASHTIME )
{
QApplication * p ;
p = hbqt_par_QApplication( 1 ) ;
if( p )
hb_retni( ( p )-cursorFlashTime() );
else
HB_TRACE.
}
Francesco, carry on.
I am onto it and have spent few hours on your previous upload.
I have noticed some points. Now I will include this patch also and will
continue to experiment. I will forward detailed analysis later.
I am not replying you because I do not want to influence your line of
thoughts.
BTW you are heading towards right direction.
Try to implement concept like this ( Przemek's code ):
pObj = ( QPointer QPageSetupDialog * )
memset( hb_gcAllocate( sizeof( QPointer QPageSetupDialog ),
s_gcQPageSetupDialog ),
0, sizeof( QPointer QPageSetupDialog ) );
* pObj = obj;
-
enjoy hbIDEing...
Pritpal Bedi
http://hbide.vouch.info/
--
View this message in context:
http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4901678.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Pritpal and Vikto, please test this generator
francesco perillo wrote: pObj = ( QPointer QPageSetupDialog * ) memset( hb_gcAllocate( sizeof( QPointer QPageSetupDialog ), s_gcQPageSetupDialog ), 0, sizeof( QPointer QPageSetupDialog ) ); It is already included it is visually different as we use object and not *object and we gcAllocate QGC_OBJECT and not directly the object... but the result is the same (should be :-) ) Sounds correct. What really surprised me is the not getting a GPF when ( p) -funz() and p is NULL. Yep, and I am surprised too. BTW this patch has provided more insight in how some objects must behave with singal/slots and events. Check for _new_QTableWidgetItem and then ProcessEvnts() firing. This is something I have to fix. I will resume the work later this evening... I miss one point: hbqt_garbage include extern ... ( void *, iParam) I already changed void * to the correct class but then I should include all the headers... I'm in a hurry I will explain better later.. Keep on, hopefully we will be on target soon. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/Pritpal-and-Vikto-please-test-this-generator-tp4900883p4902218.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: Pritpal and Vikto, please test this generator
I'm about to implement a -massivedebug switch to the generator
sample:
HB_FUNC( QT_QPUSHBUTTON_ISFLAT )
{
QPushButton * p;
HB_TRACE( HB, ( Entering function QT_QPUSHBUTTON_ISFLAT ) );
and with a bit more knowledge on parameters/object (also thanks to
Viktor generator2) we may also print the parameter passed and the
return value/pointer...
I also created my cppstub with some debug info inside... I need to
print more infos and then match one new with one delete
Ciao
Francesco
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal and Viktor on problems in hbide compiling
Hi, I spent some time with Maurizio trying to investigate the error he had this MORNING compiling hbide (QT_STRONGFOCUS non existing variable running hbide). Following his message a reply advised to do a full clean and compile. This EVENING Maurizio did a svn cleanup, then a svn update, started the compilation and everything went ok. I did a grep on today svn and found: contrib/hbqt/hbqt.ch:#define Qt_StrongFocus (actually this define was added in February) I then saw that hbide source code has #include hbqt.ch in almost all files hbide directory is NOT listed in contrib makefile so the make clean doesn't delete the temporary files You need to use -clean option with hbmk2, though this is rarely required in practice. ... more, from my tests it seems that hbmk2 doesn't recognize that hbqt.ch is changed, also if -inc is present (probably because is not in . but in ../hbqt) This is not true. What most likely happens is that you had a hbqt.ch copied into /include dir by using 'install' in the past but not using it after making subsequent incremental builds. === so there may be cases when a hbmk2 hbide.hbp is not enough after a clean/install but a full -rebuild of hbide is necessary There may be, but only for changes which aren't or cannot be detected by hbmk2, f.e. compiler version/configuration change. Even library changes are detected. If not, pls report it with '-debuginc' (and possibly more details). Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal and Viktor on problems in hbide compiling
This is not true. What most likely happens is that you had a hbqt.ch copied into /include dir by using 'install' in the past but not using it after making subsequent incremental builds. True, infact there is a hbqt.ch in /include but it should be updated by a make install shouldn't it ? Even library changes are detected. If not, pls report it with '-debuginc' (and possibly more details). Unfortunately the snadbox was updated so we can't get a snapshot. The only thing I was able to think about Maurizio error is that make clean install failed, hbqt.ch in /include was not updated, some old libs were hanging around and doing a hbmk2 hbide.hbp compiled the last version of hbide with older hbqt.ch headers and probably libs... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal and Viktor on problems in hbide compiling
This is not true. What most likely happens is that you had a hbqt.ch copied into /include dir by using 'install' in the past but not using it after making subsequent incremental builds. True, infact there is a hbqt.ch in /include but it should be updated by a make install shouldn't it ? Yes, it should. But it's easy to forget when doing an update, or it's possible that different HB_INSTALL_PREFIX was used across subsequent builds. Even library changes are detected. If not, pls report it with '-debuginc' (and possibly more details). Unfortunately the snadbox was updated so we can't get a snapshot. The only thing I was able to think about Maurizio error is that make clean install failed, hbqt.ch in /include was not updated, some old libs were hanging around and doing a hbmk2 hbide.hbp compiled the last version of hbide with older hbqt.ch headers and probably libs... 'make clean' won't clean any _installed_ files (like hbqt.ch in /include), so it didn't fail, it's just that it works this way. For best results either: a) don't use 'install' at all when working in the SVN sandbox (it makes things much cleaner), or b) set HB_INSTALL_PREFIX to any consistent location and make sure to always use 'install' when doing a 'make'. If you do any of the above consistently, such error won't happen. [ The ultimate solution would be to never install any contrib headers (and even libs) to central dirs, but this is currently not implemented, mainly because I miss input from *nix users about such layout. On win/dos/os2 this is not a problem. ] Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] To Pritpal and Viktor on problems in hbide compiling
Hi Viktor and Francesco, Yes, it should. But it's easy to forget when doing an update, or it's possible that different HB_INSTALL_PREFIX was used across subsequent builds. This was not possible as i launch same simple stored command line from many months ago and i ever used to install in the repository folder. For best results either: a) don't use 'install' at all when working in the SVN sandbox (it makes things much cleaner), or b) set HB_INSTALL_PREFIX to any consistent location and make sure to always use 'install' when doing a 'make'. I again push that I was in case b). If 'install' is unsafe could be discouraged in doc or an alert could be made in order to use it in the svn sandbox. Anyway, a deletion of all installed files via a clean flag could be the safest way of avoid this problems. [ The ultimate solution would be to never install any contrib headers (and even libs) to central dirs, but this is currently not implemented, mainly because I miss input from *nix users about such layout. On win/dos/os2 this is not a problem. ] This could be cleaner, at the price of a lot of -I directives to add in own compile scripts. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: R: [Harbour] To Pritpal and Viktor on problems in hbide compiling
Hi All, This was not possible as i launch same simple stored command line from many months ago and i ever used to install in the repository folder. For best results either: a) don't use 'install' at all when working in the SVN sandbox (it makes things much cleaner), or b) set HB_INSTALL_PREFIX to any consistent location and make sure to always use 'install' when doing a 'make'. I again push that I was in case b). If 'install' is unsafe could be discouraged in doc or an alert could be made in order to use it in the svn sandbox. 'install' is safe. It's enough to know what it does. 'install's purpose is to copy all files required to use the package to a location which the user specifies. This location is typically outside the realm of SVN. Anyway, a deletion of all installed files via a clean flag could be the safest way of avoid this problems. clean's job is not to mess with anything the user has 'install'ed. This is basic make system principle. Installed files are outside the realm of SVN or our jurisdiction. It's users responsibility to update them, or delete them. If install is a problem for someone, or someone isn't sure about what it does, it should not be used, that's all. Harbour can perfectly work on any platforms without using 'install'. I personally use 'install' only when creating a stable binary build for my own projects. For playing around, I don't use it. [ The ultimate solution would be to never install any contrib headers (and even libs) to central dirs, but this is currently not implemented, mainly because I miss input from *nix users about such layout. On win/dos/os2 this is not a problem. ] This could be cleaner, at the price of a lot of -I directives to add in own compile scripts. There is no such price, if you use .hbc files. That would be the whole point of such move actually. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] To Pritpal Bedi: About GraGetRGBIntensity( nRGBColor ) ...
Hi Pritpal Bedi:
Would your please update hbxbp: xbpgra.prg with GraGetRGBIntensity(...)
// Example: 16777215 - FF - FF, FF, FF - {255, 255, 255}
FUNCTION GraGetRGBIntensity( nRGBColor )
LOCAL aRGB := {}
LOCAL cRGBHex:=
If nRGBColor==NIL
nRGBColor := 0
Endif
cRGBHex := HB_HexToStr( HB_NumToHex( nRGBColor ) )
cRGBHex := PADL( cRGBHex, 6, 0)
aRGB := { SubStr(cRGBHex,1,2), SubStr(cRGBHex,3,2), SubStr(cRGBHex,5,2) }
aRGB := { HB_HexToNum(aRGB[1]), HB_HexToNum(aRGB[2]),
HB_HexToNum(aRGB[3]) }
RETURN aRGB
(But I havenot testing it ...)
Shum
--
View this message in context:
http://n2.nabble.com/To-Pritpal-Bedi-About-GraGetRGBIntensity-nRGBColor-tp4870368p4870368.html
Sent from the harbour-devel mailing list archive at Nabble.com.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal Bedi: About oDlg:drawingArea:clipChildren ??
Very intresting your sample!
Have you other xbp sample?
i confirm problem and then i add a litte problen regarding hbide
with your source named xpp01.prg
using Follow is my xpp01.hbp
-3rd=hbide_version=1.0
-3rd=hbide_type=Executable
-3rd=hbide_title=xpp01
-3rd=hbide_location=C:\harbour\max\
-3rd=hbide_workingfolder=
-3rd=hbide_destinationfolder=
-3rd=hbide_output=xpp01
-3rd=hbide_launchparams=
-3rd=hbide_launchprogram=
-3rd=hbide_backupfolder=
xpp01.prg
C:\harbour\contrib\hbxbp\hbxbp.hbc
I can compile and run with hbmk2
if i execute hbide xpp01.hpp with
C:\harbour\max\harbour\contrib\hbide\hbide c:\harbour\max\xpp01.hbp
when compile and execute it not be executed
Project [ xpp01 ] Launch [ Yes ] Rebuild [ No ] Started [ 17:42:06 ]
: Do Not Exists
/C hbmk2 C:\harbour\max\xpp01.hbp -q -trace -info -lang=en
Starting in: harbour\max : C:\harbour\max\
hbmk2: Processing environment options: -compiler=mingw
hbmk2: Autodetected platform: win
hbmk2: Using Harbour: C:\HARBOUR\bin C:\HARBOUR\include
C:\HARBOUR\lib\win\mingw C:\HARBOUR\lib\win\mingw
hbmk2: Processing: C:\harbour\contrib\hbxbp\hbxbp.hbc
hbmk2: Processing: C:\harbour\contrib\hbxbp\../hbqt/hbqt.hbc
hbmk2: Harbour compiler command (embedded):
(C:\HARBOUR\BIN\WIN\mingw\harbour.exe) -n2 C:/harbour/max/xpp01.prg -q
-oC:\Users\MBELGR~1.SED\AppData\Local\Temp\ -iC:/HARBOUR/include
-iC:/harbour/contrib/hbxbp -iC:/harbour/contrib/hbqt
Harbour 2.1.0dev (Rev. 14276)
Copyright (c) 1999-2010, http://www.harbour-project.org/
hbmk2: C/C++ compiler command:
gcc.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -Wall -W
-pipe -IC:/HARBOUR/include -IC:/harbour/contrib/hbxbp
-IC:/harbour/contrib/hbqt C:\Users\MBELGR~1.SED\AppData\Local\Temp\xpp01.c
-o C:/Users/MBELGR~1.SED/AppData/Local/Temp/xpp01.o
hbmk2: C/C++ compiler command:
gcc.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -Wall -W
-pipe -IC:/HARBOUR/include -IC:/harbour/contrib/hbxbp
-IC:/harbour/contrib/hbqt
C:\Users\MBELGR~1.SED\AppData\Local\Temp\hbmk_9eg2h2.c -o
C:/Users/MBELGR~1.SED/AppData/Local/Temp/hbmk_9eg2h2.o
hbmk2: C/C++ compiler command:
g++.exe -c -O3 -march=i586 -mtune=pentiumpro -fomit-frame-pointer -Wall -W
-pipe -IC:/HARBOUR/include -IC:/harbour/contrib/hbxbp
-IC:/harbour/contrib/hbqt
C:\Users\MBELGR~1.SED\AppData\Local\Temp\hbmk_j9i5vv.cpp -o
C:/Users/MBELGR~1.SED/AppData/Local/Temp/hbmk_j9i5vv.o
hbmk2: Linker command:
gcc.exe C:\Users\MBELGR~1.SED\AppData\Local\Temp\xpp01.o
C:\Users\MBELGR~1.SED\AppData\Local\Temp\hbmk_9eg2h2.o
C:\Users\MBELGR~1.SED\AppData\Local\Temp\hbmk_j9i5vv.o -mwindows
-Wl,--start-group -lhbxbp -lhbqt -lhbqtcore -lhbqtgui -lhbqtnetwork
-lversion -lshlwapi -lQtCore4 -lQtGui4 -lQtNetwork4 -lQtUiTools -lpsapi
-lsupc++ -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi
-lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd
-lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro
-lhbcplr -lhbpp -lhbcommon -lhbmainwin -lkernel32 -luser32 -lgdi32
-ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid
-lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet
-lhbpcre -lhbzlib -Wl,--end-group -oxpp01.exe -LC:/HARBOUR/lib/win/mingw
-LC:/DEVL/qt/4.5.3/lib
Exit Code [ 0 ] Exit Status [ 0 ] Finished at [ 17:42:09 ] Done in [ 2.52
Secs ]
Launch error: file not found - \xpp01.exe
2010/4/8 Shum wcshu...@hotmail.com
Hi Prital Bedi,
I find that hbxbp is not compitable to Xbase++ as follow:
oDlg:drawingArea:clipChildren := .T. (In Xbase++ ... it is exported var
without error)
http://www.mingyik.com/dnload/stxbp10.jpg
Sample source as follow:
#include xbp.ch
#include Appevent.ch
Function AppSys()
Return( NIL )
Function Main( P1 )
LOCAL nEvent, mp1, mp2, oXbp
LOCAL oDlg, oMenuBar, oMenu
Local oAppDlg:=AppDesktop()
Local lTestFlag:=.F.
If P1NIL
lTestFlag := .T.
Endif
// Create dialog
oDlg := XbpDialog():new( oAppDlg , , {30,50}, {400,250} )
oDlg:title := Harbour + QT + hbxbp Dialog with Menubar
oDlg:clipChildren := .T.
oDlg:drawingArea:clipChildren := .T.
oDlg:create()
If lTestFlag
oXbp := Xbpstatic():new( oDlg:drawingArea, oDlg, {20,100},
{100,25}, , .T. )
oXbp:type := XBPSTATIC_TYPE_TEXT
oXbp:options := XBPSTATIC_TEXT_CENTER + XBPSTATIC_TEXT_VCENTER
oXbp:caption :=
[Harbour] To Pritpal and Viktor on problems in hbide compiling
I spent some time with Maurizio trying to investigate the error he had this MORNING compiling hbide (QT_STRONGFOCUS non existing variable running hbide). Following his message a reply advised to do a full clean and compile. This EVENING Maurizio did a svn cleanup, then a svn update, started the compilation and everything went ok. I did a grep on today svn and found: contrib/hbqt/hbqt.ch:#define Qt_StrongFocus (actually this define was added in February) I then saw that hbide source code has #include hbqt.ch in almost all files hbide directory is NOT listed in contrib makefile so the make clean doesn't delete the temporary files ... more, from my tests it seems that hbmk2 doesn't recognize that hbqt.ch is changed, also if -inc is present (probably because is not in . but in ../hbqt) === so there may be cases when a hbmk2 hbide.hbp is not enough after a clean/install but a full -rebuild of hbide is necessary Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: [Pritpal] HBIDE editor tabs illegible
On 25/02/10 23:45, Pritpal Bedi wrote: Barry Jackson wrote: One other point. Double clicking functions in the function pane finds the function, but it places the first line of the function at the bottom of the edit window, so always has to be scrolled up. :-( This depends on the current cursor position. If it is above the found line, editor scrolls it to bottom, otherwise to top. I am aware of this fact and will concentrate a little later. Remind me once more next week, if I forget. That now works fine - nice. However the edit window tab labels are still the same in Linux. http://i115.photobucket.com/albums/n287/barjac_2006/hbide1.png Rgds Happy Easter! Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: [Pritpal] HBIDE editor tabs illegible
Barry Jackson wrote: However the edit window tab labels are still the same in Linux. http://i115.photobucket.com/albums/n287/barjac_2006/hbide1.png It is difficult for me to fix it as I do not have linux setup. Can you play with following lines in idestylesheet.prg: aadd( txt_, 'border: 2px solid #94C4C3; ' ) aadd( txt_, 'border-bottom-color: #C2C7CB; /* same as the pane color */ ' ) aadd( txt_, 'border-top-left-radius: 6px; ' ) aadd( txt_, 'border-top-right-radius: 6px; ' ) aadd( txt_, 'min-width: 8px; ' ) aadd( txt_, 'padding: 2px; ' ) Try to change *px values and do some experiments. And please report back what values are right for linux. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Pritpal-HBIDE-editor-tabs-illegible-tp4632574p4846950.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] To Pritpal
Hi Pritpal, Yesterday I sent a message to your private email address about the GPF... did you receive it ? Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: [Pritpal] HBIDE editor tabs illegible
On 03/04/10 14:26, Pritpal Bedi wrote: Barry Jackson wrote: However the edit window tab labels are still the same in Linux. Try to change *px values and do some experiments. And please report back what values are right for linux. OK it's sorted. The problem was the KDE style for widgets I had selected in the desktop environment. There are several available :- CDE Cleanlooks GTK+ LaOra-KDE == LaOra-Qt Motif Oxygen == Plastique Windows There are only two that are bad for HBIDE (==). I was using Oxygen ! I have switched to LaOra-Qt and it's fine. http://i115.photobucket.com/albums/n287/barjac_2006/hbide3.png The bad styles also shrink the text boxes in the Tools Utils dialogue. Changing the *px values did not affect the text at all, just the tab size/borders etc. So that's one less TODO for you! :-) Rgds, Barry ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: [Pritpal] HBIDE editor tabs illegible
Barry Jackson wrote: So that's one less TODO for you! :-) :- - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Pritpal-HBIDE-editor-tabs-illegible-tp4632574p4848637.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: [Pritpal] HBIDE editor tabs illegible
Barry Jackson wrote: In Mandriva Linux 2010.0 I am seeing this:- http://i115.photobucket.com/albums/n287/barjac_2006/hbide1.png The tab titles are not readable. Also there is no response to File-new-project. I can find no way to open multiple .prg files. Like - navigate to a folder and open *.prg and then save as a project ? Maybe I am missing something ;-/ Good work so far! I suppose Qt is painting tabs title a little above the ground and is not using native rendering. I will see if we can control the tab size anyway. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Pritpal-HBIDE-editor-tabs-illegible-tp4632574p4633201.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: [Pritpal] HBIDE editor tabs illegible
Barry Jackson wrote: Also there is no response to File-new-project. It is the direct effect of latest changes. I will fix in a while. Alternatively, right click on Projects node in projects tree at the left, and select this option. I can find no way to open multiple .prg files. It is there. When fole-open dialog is presented, select multiple files with ctrl+click, and then presee open. Like - navigate to a folder and open *.prg and then save as a project ? Maybe I am missing something ;-/ Can you detail how you want this feature to work. The otherway around is there. Follow right-click on Projects node. Good work so far! Thank you. BTW, I am writing a brief help and hope it to be ready to some extent to be usable this weekend. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Pritpal-HBIDE-editor-tabs-illegible-tp4632574p4633557.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: [Pritpal] HBIDE editor tabs illegible
On 25/02/10 16:33, Pritpal Bedi wrote: Barry Jackson wrote: I can find no way to open multiple .prg files. It is there. When fole-open dialog is presented, select multiple files with ctrl+click, and then presee open. No - it's not working here. With CTRL held down, clicking a file opens it rather than selecting it. SHIFT (with care) will sometimes open multiple files, but it's not working properly. I thought that it may have been to do with my having single click set system wide to open files, but disabling that changes nothing. Also the filter is not remembered between each use of the file open dialog. It always defaults to *.* after setting to *.prg. Like - navigate to a folder and open *.prg and then save as a project ? Maybe I am missing something ;-/ Can you detail how you want this feature to work. In the file open dialog, navigate to a folder and type *.prg in the file name field and click open. All .prg files would be listed in the editor tabs pane in one go. The otherway around is there. Follow right-click on Projects node. Tried that but nothing happens. No, I can't see how to save a session as a project, or create a project, but I will await your help files. BTW, I am writing a brief help and hope it to be ready to some extent to be usable this weekend. Great! ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: [Pritpal] HBIDE editor tabs illegible
On 25/02/10 23:14, Barry Jackson wrote: The otherway around is there. Follow right-click on Projects node. OK found it! The projects panel was appearing UNDER the functions panel, so I saw no change! I will keep playing. One other point. Double clicking functions in the function pane finds the function, but it places the first line of the function at the bottom of the edit window, so always has to be scrolled up. :-( ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: [Pritpal] HBIDE editor tabs illegible
Barry Jackson wrote: One other point. Double clicking functions in the function pane finds the function, but it places the first line of the function at the bottom of the edit window, so always has to be scrolled up. :-( This depends on the current cursor position. If it is above the found line, editor scrolls it to bottom, otherwise to top. I am aware of this fact and will concentrate a little later. Remind me once more next week, if I forget. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Pritpal-HBIDE-editor-tabs-illegible-tp4632574p4636195.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal about hbide
Easy hbmk2 hbide Bruno 2009/11/21 francesco perillo fperi...@gmail.com I have to understand how to compile hbide (with Qt) before . :-) Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal about hbide
You can start adding 2009/11/20 francesco perillo fperi...@gmail.com: Hi, I was told that hbide will integrate support for svn... Since I'm an user of Mercurial I'd like to talk with you to cooperate to add support for this dvcs... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano Iscritto all'albo dei CTU presso il Tribunale di Novara per materia Informatica Delta Informatica S.r.l. (http://www.deltain.it/) (+39 0321 455962) Analisi e sviluppo software per Lan e Web - Consulenza informatica - Formazione ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal about hbide
I have to understand how to compile hbide (with Qt) before . :-) Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] To Pritpal about hbide
Hi, I was told that hbide will integrate support for svn... Since I'm an user of Mercurial I'd like to talk with you to cooperate to add support for this dvcs... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] To Pritpal about hbide
Hi francesco perillo-2 wrote: I was told that hbide will integrate support for svn... Since I'm an user of Mercurial I'd like to talk with you to cooperate to add support for this dvcs... Probably it is too early a question/solution integration during the process of HDIDE evolution. Let we first reach project management stage. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/To-Pritpal-about-hbide-tp26446002p26451351.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
