[Harbour] Getting errors and warnings in MinGW compile
I receive the messages below trying to compile latest CVS versions with MinGW. hbmk2: Error: Running Harbour compiler (internal). 1 hbi18n.o:hbi18n.c:(.text+0x2c): undefined reference to `hb_vmProcessSymbolsEx' c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(845) Warning W0001 Ambiguous reference 'HB_VERSION_BUILD_PLAT' c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(1102) Warning W0001 Ambiguous reference 'HB_VERSION_BUILD_COMP' c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(5832) Warning W0001 Ambiguous reference 'HB_VERSION_BUILD_PLAT' c:/include\common.ch(85) Warning W0001 Redefinition or duplicate definition of #define HB_SYMBOL_UNUSED The commands given to compile are: Win-make clean Win-make install TIA for your answer. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Getting errors and warnings in MinGW compile
I confirm the persistence of the problem also after updating to: ChangeLog 12446 2009-09-09 00:24:54Z druzus No other one reports same problem? Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: Maurizio la Cecilia [mailto:m.laceci...@gmail.com] > Inviato: martedì 8 settembre 2009 18.08 > A: harbour@harbour-project.org > Oggetto: [Harbour] Getting errors and warnings in MinGW compile > > I receive the messages below trying to compile latest CVS > versions with > MinGW. > > hbmk2: Error: Running Harbour compiler (internal). 1 > hbi18n.o:hbi18n.c:(.text+0x2c): undefined reference to > `hb_vmProcessSymbolsEx' > > c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(845) Warning > W0001 Ambiguous > reference 'HB_VERSION_BUILD_PLAT' > > c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(1102) Warning > W0001 Ambiguous > reference 'HB_VERSION_BUILD_COMP' > > c:/CVS/harbour/bin/../utils/hbmk2/hbmk2.prg(5832) Warning > W0001 Ambiguous > reference 'HB_VERSION_BUILD_PLAT' > > c:/include\common.ch(85) Warning W0001 Redefinition or > duplicate definition > of #define HB_SYMBOL_UNUSED > > The commands given to compile are: > > Win-make clean > Win-make install > > TIA for your answer. > > Maurizio la Cecilia > > > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] Getting errors and warnings in MinGW compile
> Da: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] > Inviato: mercoledì 9 settembre 2009 10.10 > A: Harbour Project Main Developer List. > Oggetto: Re: R: [Harbour] Getting errors and warnings in MinGW compile > > On Wed, 09 Sep 2009, Maurizio la Cecilia wrote: > > Hi, > > > I confirm the persistence of the problem also after updating to: > > ChangeLog 12446 2009-09-09 00:24:54Z druzus > > No other one reports same problem? > > There is no problem with current SVN code but we have > never ending problem with asking users to make _CLEAN_ > build after syncing with SVN and before reporting problems ;-) > > Please execute: >make clean > before: >make > > I believe it will help. If not then please report the problem. > Otherwise such messages only confuse other users. > > best regards, > Przemek > > As said in my first message: > The commands given to compile are: > > Win-make clean > Win-make install > Thus, if i don't missed something, the problem is real. I ever compiled fine using those commands. I advise also that, to avoid conflicts with old versions, i tried to compile after a fresh checkout from repository, but the result is the same. Anyway, if i risk only to confuse other users, don't worry about this problem if seems to be only of mine. Best regards, Maurizio ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] Getting errors and warnings in MinGW compile
After this commit: 2009-09-09 18:12 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * bin/postinst.bat ! Fixed for dos shells. (cmdline lenght problems, end of .cfg extension was clipped on the longest line to .cf) all returned to work fine. Thanks. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: Maurizio la Cecilia [mailto:m.laceci...@gmail.com] > Inviato: mercoledì 9 settembre 2009 10.48 > A: 'Harbour Project Main Developer List.' > Oggetto: R: R: [Harbour] Getting errors and warnings in MinGW compile > > > > Da: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] > > Inviato: mercoledì 9 settembre 2009 10.10 > > A: Harbour Project Main Developer List. > > Oggetto: Re: R: [Harbour] Getting errors and warnings in > MinGW compile > > > > On Wed, 09 Sep 2009, Maurizio la Cecilia wrote: > > > > Hi, > > > > > I confirm the persistence of the problem also after updating to: > > > ChangeLog 12446 2009-09-09 00:24:54Z druzus > > > No other one reports same problem? > > > > There is no problem with current SVN code but we have > > never ending problem with asking users to make _CLEAN_ > > build after syncing with SVN and before reporting problems ;-) > > > > Please execute: > >make clean > > before: > >make > > > > I believe it will help. If not then please report the problem. > > Otherwise such messages only confuse other users. > > > > best regards, > > Przemek > > > > > > As said in my first message: > > > The commands given to compile are: > > > > Win-make clean > > Win-make install > > > > Thus, if i don't missed something, the problem is real. > I ever compiled fine using those commands. > I advise also that, to avoid conflicts with old versions, i > tried to compile > after a fresh checkout from repository, but the result is the same. > Anyway, if i risk only to confuse other users, don't worry about this > problem if seems to be only of mine. > Best regards, > Maurizio > > > ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: R: [Harbour] Getting errors and warnings in MinGW compile
Ok. As usual, you're right. I missed some changes in environment variables naming and solved updating the settings. Gone confused because was in postinst.bat execution that i received the error messages. My apologies to you and Przemek. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: Viktor Szakáts [mailto:harbour...@syenar.hu] > Inviato: mercoledì 9 settembre 2009 20.38 > A: Harbour Project Main Developer List. > Oggetto: Re: R: R: [Harbour] Getting errors and warnings in > MinGW compile > > I didn't aim to fix anything based on your report, > just added some new unrelated features. > > You probably fixed your environment in between. > > Notice that such lines: > > c:/include\common.ch(85) Warning W0001 Redefinition or > > duplicate definition > > are telling almost 100% that something IS wrong with your > environment if your SVN source tree otherwise resides in > C:\CVS\harbour (which is seen in other log lines in your report). > > Brgds, > Viktor > > On 2009.09.09., at 20:11, Maurizio la Cecilia wrote: > > > After this commit: > > > > 2009-09-09 18:12 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) > > * bin/postinst.bat > >! Fixed for dos shells. (cmdline lenght problems, end of .cfg > > extension was clipped on the longest line to .cf) > > > > all returned to work fine. > > Thanks. > > Best regards. > > Maurizio la Cecilia > > > > > > > > > >> -Messaggio originale- > >> Da: Maurizio la Cecilia [mailto:m.laceci...@gmail.com] > >> Inviato: mercoledì 9 settembre 2009 10.48 > >> A: 'Harbour Project Main Developer List.' > >> Oggetto: R: R: [Harbour] Getting errors and warnings in > MinGW compile > >> > >> > >>> Da: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] > >>> Inviato: mercoledì 9 settembre 2009 10.10 > >>> A: Harbour Project Main Developer List. > >>> Oggetto: Re: R: [Harbour] Getting errors and warnings in > >> MinGW compile > >>> > >>> On Wed, 09 Sep 2009, Maurizio la Cecilia wrote: > >>> > >>> Hi, > >>> > >>>> I confirm the persistence of the problem also after updating to: > >>>> ChangeLog 12446 2009-09-09 00:24:54Z druzus > >>>> No other one reports same problem? > >>> > >>> There is no problem with current SVN code but we have > >>> never ending problem with asking users to make _CLEAN_ > >>> build after syncing with SVN and before reporting problems ;-) > >>> > >>> Please execute: > >>> make clean > >>> before: > >>> make > >>> > >>> I believe it will help. If not then please report the problem. > >>> Otherwise such messages only confuse other users. > >>> > >>> best regards, > >>> Przemek > >>> > >>> > >> > >> As said in my first message: > >> > >>> The commands given to compile are: > >>> > >>> Win-make clean > >>> Win-make install > >>> > >> > >> Thus, if i don't missed something, the problem is real. > >> I ever compiled fine using those commands. > >> I advise also that, to avoid conflicts with old versions, i > >> tried to compile > >> after a fresh checkout from repository, but the result is the same. > >> Anyway, if i risk only to confuse other users, don't worry > about this > >> problem if seems to be only of mine. > >> Best regards, > >> Maurizio > >> > >> > >> > > > > ___ > > 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
R: [Harbour] How do I know if the button was pressed?
I think that when cVar1 get lost his focus and valid clause is evaluated the
pushbutton hit focus but not yet sets the buffer property.
You could try with:
FUNCTION Func1(xVar1, xGetList)
RETURN xGetList[3]:hasFocus .or. !EMPTY(xVar1)
Not tested, however, as i don't use cl53 behaviour.
Best regards.
Maurizio la Cecilia
> -Messaggio originale-
> Da: Guillermo Varona Silupú [mailto:gvar...@ec-red.com]
> Inviato: giovedì 17 settembre 2009 0.31
> A: Harbour Project Main Developer List.
> Oggetto: [Harbour] How do I know if the button was pressed?
>
> In this code:
> **
> #include "Inkey.ch"
> PROCEDURE Main
> LOCAL cVar1 := cVar2 := SPAC(10), oPsw, GetList := {}, lBtn := .T.
> SET(_SET_EVENTMASK, INKEY_ALL)
> MSETCURSOR(.T.)
> SETMODE(25,80)
> CLS
> @ 10, 10 SAY "Entrada1:" GET cVar1 VALID Func1(cVar1,GetList)
> @ 11, 10 SAY "Entrada2:" GET cVar2
> @ 12, 10 GET lBtn PUSHBUTTON CAPTION " E&xit " STATE {||
> ReadKill(.T.)}
> COLOR "W/G,W+/G,G/N,W+/G"
> READ
> return
>
> FUNCTION Func1(xVar1, xGetList)
> ? xGetList[3]:buffer
> wait
> RETURN !EMPTY(xVar1)
> *
> How do I know if the button was pressed?
>
> Buffer is supposed to contain this information, but always returns NIL
> The idea is to exit the program by pressing the button, even if this
> cVar1 empty, but the VALID clause does not.
>
> Any help / idea?
>
> TIA
> Best Regards
> GVS
>
>
>
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] LETODB to harbour svn ?
I can only agree to LetoDB contrib inclusion. Same history has hwGUI: Alex become unreachable and the project quite stopped. Only when a group of developers got control and involved new guys the lib returned to grow and new features was introduced, mainly by Luis Fernando Basso. Alex is very busy and not ever present, so the partecipation of a greater team of developers can guarantee the life of the project, giving value to the very strong and effective Alex's work. Best regards. Maurizio la Cecilia -- View this message in context: http://www.nabble.com/LETODB-to-harbour-svn---tp25612291p25623103.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] hbQT don't builds
Hi Pritpal and all, after the last changes i obtain this error building the hbQT libs. gcc -I. -I../../../../../include -Wall -W -O3 -fomit-frame-pointer -march=i586 -mtune=pentiumpro -Ic:\qt\qt\include -Ic:\qt\qt\include/Qt -Ic:\qt\qt\include/ QtCore -Ic:\qt\qt\include/QtGui -Ic:\qt\qt\include/QtNetwork -Ic:\qt\qt\include/ QtWebKit -ohbqt_destruct.o -c ../../../hbqt_destruct.cpp ../../../hbqt_destruct.cpp: In function `void* hbqt_gcpointer(int)': ../../../hbqt_destruct.cpp:101: error: cannot convert `void (*)(void*)' to `cons t HB_GC_FUNCS*' for argument `1' to `void* hb_parptrGC(const HB_GC_FUNCS*, int)' ../../../hbqt_destruct.cpp: In function `void* hbqt_ptrTOgcpointer(void*, void ( *)(void*))': ../../../hbqt_destruct.cpp:115: error: `hb_gcAlloc' was not declared in this sco pe ../../../hbqt_destruct.cpp:115: warning: unused variable 'hb_gcAlloc' ../../../hbqt_destruct.cpp: At global scope: ../../../hbqt_destruct.cpp:122: warning: unused parameter 'name' win-make[3]: *** [hbqt_destruct.o] Error 1 win-make[2]: *** [descend] Error 2 win-make[1]: *** [hbqt.inst] Error 2 win-make: *** [contrib.inst] Error 2 Obviously, i use the MinGW compiler in a XP environment. The command given is: win-make clean install Best regards. Maurizio la Cecilia -- View this message in context: http://www.nabble.com/hbQT-don%27t-builds-tp26030069p26030069.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] HBIDE - An Overview
Hi Pritpal, as very hot fan of xMate and happy user of the product of Andy, i would partecipate to your new project. You can count on me surely as betatester and, due to prg based development, also in working on not critical pieces of the project, if you need. Many thanks for your effective work, and best regards. Maurizio la Cecilia -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26385643.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
Re: [Harbour] HBIDE - An Overview : Application Icon
This is based on the wizard idea. Pritpal Bedi wrote: > > Hello All > > Can some of you provide a descent icon for HBIDE.exe ? > > Regards > Pritpal Bedi > > http://old.nabble.com/file/p26386453/hbIde1.ico hbIde1.ico -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26386453.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
Re: [Harbour] HBIDE - An Overview : Application Icon
... and this on the creative work of programming. Best regards. Maurizio la Cecilia Pritpal Bedi wrote: > > Hello All > > Can some of you provide a descent icon for HBIDE.exe ? > > Regards > Pritpal Bedi > > http://old.nabble.com/file/p26386461/hbIde2.ico hbIde2.ico -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26386461.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
Re: [Harbour] HBIDE - An Overview
Again, about hbIDE, i would know what Pritpal and the community thinks about some choices i believe strategical in the new project. A) A feature of xMate that i think needs to be absolutely present in hbIDE is the project embedding. I can, i.e., define a production project enumerating the own files AND adding to xbp also the linked subprojects (also xbp, of course) as the engine library project, the gui library project, and so on. This declaration allows to build in cascade the subprojects and the main project if some change was made in any source, not important if of main or sub projects. Also, the open file allows to work in the same instance of xMate editing any source of main or sub projects. B) Another very useful tool is the formatter. Obviously, the better choice is to integrate the hbformat work of Alex Kresin published in the contrib, after investigating if it lacks of some feature of the highly configurable formatter of xMate. If is needed some aid about this tool, i could be useful. C) A lack (but maybe the only important) of xMate is about the tiled and aligned windows, so is needed to open two instances of xMate and to arrange the windows manually to see two sources simultaneously. The behaviour of the first hbIDE release mantains the same as xMate, so i think better to evaluate if a tab rearranging or a MDI approach could be a solution. Waiting for your thought about. Best regards. Maurizio la Cecilia Maurizio la Cecilia wrote: > > Hi Pritpal, > as very hot fan of xMate and happy user of the product of Andy, i would > partecipate to your new project. > You can count on me surely as betatester and, due to prg based > development, also in working on not critical pieces of the project, if you > need. > Many thanks for your effective work, and best regards. > Maurizio la Cecilia > -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26404961.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
Re: [Harbour] SF.net SVN: harbour-project:[12922] trunk/harbour
Hi Pritpal, the close button no loger works and clicking it the app crashes with: Application Internal Error - C:\CVS\harbour\contrib\hbide\hbide.exe Terminated at: 2009.11.18 10:55:39 Unrecoverable error 6005: Exception error: Exception Code:C005 Exception Address:65182370 EAX: EBX:00C6E2F8 ECX:003EFEE0 EDX:0800F000 ESI: EDI:01ACB258 EBP:0022FD68 CS:EIP:001B:65182370 SS:ESP:0023:0022FCB0 DS:0023 ES:0023 FS:003B GS: Flags:00010282 CS:EIP: 8B 40 04 89 5C 24 04 C7 45 88 03 00 00 00 89 04 SS:ESP: 003EFE98 0022FCD8 6A3939F0 0005 0022FD8C 003E 005E51A8 003EFE98 00C6E2F8 0001FD0C 0006 0022FC44 0022FD8C C stack: EIP: EBP: Frame: OldEBP, RetAddr, Params... 65182370 0022FD68 65AD7508 00475ED5 00C6E2F8 0022FDC0 0022FFE0 77C05C94 77BE2070 0001 00C7853C Environment: XP win workstation, MinGW compiler, latest CVS Harbour build. Best regards. Maurizio la Cecilia vouchcac wrote: > > Revision: 12922 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12922&view=rev > Author: vouchcac > Date: 2009-11-18 01:31:26 + (Wed, 18 Nov 2009) > > Log Message: > --- > 2009-11-17 17:26 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbide/hbide.prg > + contrib/hbide/resources/builderror.png > * contrib/hbide/resources/gotomark.png > + contrib/hbide/resources/modulelist.png > > * contrib/hbqt/hbqt_slots.cpp > * contrib/hbqt/hbqt_slots.h > * contrib/hbqt/moc_slots.cpp > > * contrib/hbxbp/xbpgeneric.prg > * contrib/hbxbp/xbptabpage.prg > + Implemented first 4 icons operational. > Now, at least you can open/edit/save .prg .c .ch .h files. > I am interested in any bugs you may encounter in the process. > Few HBXBP calasses have also been updated in the process. > > QUESTION: How good it will be to extend Xbase++ class framework ? > Is this the ripe time or we need more inputs ? > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/contrib/hbide/hbide.prg > trunk/harbour/contrib/hbide/resources/gotomark.png > trunk/harbour/contrib/hbqt/hbqt_slots.cpp > trunk/harbour/contrib/hbqt/hbqt_slots.h > trunk/harbour/contrib/hbqt/moc_slots.cpp > trunk/harbour/contrib/hbxbp/xbpgeneric.prg > trunk/harbour/contrib/hbxbp/xbptabpage.prg > > Added Paths: > --- > trunk/harbour/contrib/hbide/resources/builderror.png > trunk/harbour/contrib/hbide/resources/modulelist.png > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12922--trunk-harbour-tp26400975p26405193.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
Re: [Harbour] HBIDE - An Overview
Never aimed to reuse or xbp files or preserve xbp format, but to recover the concept of embedded subproject. hbmk2 IS the Harbour builder and .hb* files are the standard format. The target is to have a generated hbp file capable to rebuild not only the source of the main project, but also the linked library declared as subproject, including i.e. hbc files as subprojects. Maybe a directive to declare that the lib isn't only to be linked, but also to be edited and, if needed, rebuilded could do the job. hbIde could recognize this parameter and could allow to open also the subproject sources in the editor and after, at build time, assure that the lib declared as subprojects are parsed by hbmk2 BEFORE the build of the main project. This is what xMate smartly does. If you are parallely developing a production/test program and a subset of libraries on that you're working hard, the benefits of this approach is unvaluable in terms of clarity, speed and safety. Try to make the same job with other project managers, also very effective as xDevStudio, and you'll return quickly to xMate... After the growth of hbmk2 to powerful and mature tool, quite all the jobs of a project manager could be obtained also with a good configuration of a smart editor as Notepad++, but this concept is very hard to implement out of an integrated tool. Best regards, Maurizio Viktor Szakáts wrote: > > It would be quite a huge waste of effort if hbide would > reinvent the whole feature set of hbmk2. > > IMO it should be able to create .hbp files for each project > on the fly (from the file lists and options set on the GUI) > and call hbmk2 to do this job. > > Overall I think .xbp file compatibility is unimportant, > but of course hbide could use something similar to store > the file list and options. Ideally it should store these > in .hbp files. This will need a hbmk2 compatible option > parser. > > Brgds, > Viktor > > On 2009 Nov 18, at 10:44, Maurizio la Cecilia wrote: > >> >> Again, about hbIDE, i would know what Pritpal and the community thinks >> about >> some choices i believe strategical in the new project. >> >> A) A feature of xMate that i think needs to be absolutely present in >> hbIDE >> is the project embedding. I can, i.e., define a production project >> enumerating the own files AND adding to xbp also the linked subprojects >> (also xbp, of course) as the engine library project, the gui library >> project, and so on. This declaration allows to build in cascade the >> subprojects and the main project if some change was made in any source, >> not >> important if of main or sub projects. Also, the open file allows to work >> in >> the same instance of xMate editing any source of main or sub projects. >> >> B) Another very useful tool is the formatter. Obviously, the better >> choice >> is to integrate the hbformat work of Alex Kresin published in the >> contrib, >> after investigating if it lacks of some feature of the highly >> configurable >> formatter of xMate. If is needed some aid about this tool, i could be >> useful. >> >> C) A lack (but maybe the only important) of xMate is about the tiled and >> aligned windows, so is needed to open two instances of xMate and to >> arrange >> the windows manually to see two sources simultaneously. The behaviour of >> the >> first hbIDE release mantains the same as xMate, so i think better to >> evaluate if a tab rearranging or a MDI approach could be a solution. >> >> Waiting for your thought about. >> Best regards. >> Maurizio la Cecilia >> >> >> Maurizio la Cecilia wrote: >>> >>> Hi Pritpal, >>> as very hot fan of xMate and happy user of the product of Andy, i would >>> partecipate to your new project. >>> You can count on me surely as betatester and, due to prg based >>> development, also in working on not critical pieces of the project, if >>> you >>> need. >>> Many thanks for your effective work, and best regards. >>> Maurizio la Cecilia >>> >> >> -- >> View this message in context: >> http://old.nabble.com/HBIDE---An-Overview-tp26379927p26404961.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 > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/HBIDE---An-Overview-tp26379927p26406788.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
R: [Harbour] HBIDE - An Overview
> I don't plan to add subproject layout support to hbmk2
> itself ATM, but it seems to be easily doable by calling
> hbmk2 with .hbp files in _proper order_. Such job can be
> done by hbide.
I agree. I think that the concept would be encapsulated in hbIDE, not in
hbmk2.
> To be more precise hbmk2 already supports multiple
> projects, but caller should provide proper ordering
> of these projects:
>
> - myapp.hbp
> - mylib1.hbp
> - mylib2.hbp
> - mysublib1.hbp
>
> =>
>
> hbmk2 mylib1.hbp mysublib1.hbp mylib2.hbp myapp.hbp
>
> Maybe later we can introduce a concept of .hbs ("solution"?)
> file which could describe such tree layout which can
> be internally converted to .hbp filelist in proper order.
>
> Or alternatively some sort of cmdline markup to denote
> such tree: hbmk2 myapp.hbp (mylib1.hbp, mylib2.hbp (mysublib1.hbp))
This could be made by hbIDE, based on own project file describing the
hierarchy of the project.
I think a xMate's .xbp counterpart will a must for hbIDE to treat a project
as a organic object.
>
> If someone develops such parsing and tree flattening
> logic separately from hbmk2, it can be moved to hbmk2
> even easier at some point.
Also, but seems to overload the hbmk2 mission.
> I do this very easily:
>hbmk2 lib1.hbp lib2.hbp app.hbp
Yes. I realize that, but i was meaning at edit time. In xMate the subproject
are seen as part of the main project and isn't nedded to jump from one
project to other in order to edit the sources. Other project managers treat
each project separately and is time consuming and confusing to manage
related sources contained in different projects.
Best regards,
Maurizio
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] hbformat, Where is the error?
No errors in your code. The problem is the: IF ; This format is not handled by hbformat. Avoiding the ; and splitting as usual into multiple lines does the job. Anyway, a thing to signal to Alex Kresin. Best regards. Maurizio la Cecilia ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbformat, Where is the error?
You are right. Because of this i posted about hbformat integration with xMate formatter features in hbIDE project. The Harbour's universe is very large and a lot of commands and functions could be found in Harbour sources, depending from the used libraries. xMate solves this problem in a very effective fashion allowing high configurability of keywords and formatting styles. Best regards. Maurizio Bruno Luciani wrote: > > Maurizio , I just Try HBformat ina a mix PRG > > Harbour + OOHG ( minigui ) > > and giveme an error on line 38 > > Reformatting factura.prg > <. > Error 3 on line 38 : END BROWSE > > But appears to be reformated ok > > Its posible ? I think that Hbformat reformat ok but not recognizes an > oohg > command > > I am right ? > > Bruno > > > > 2009/11/18 Maurizio la Cecilia > >> No errors in your code. >> > > >> >> The problem is the: >> >> IF ; >> >> This format is not handled by hbformat. >> Avoiding the ; and splitting as usual into multiple lines does the job. >> Anyway, a thing to signal to Alex Kresin. >> Best regards. >> >> Maurizio la Cecilia >> >> >> >> ___ >> 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 > > -- View this message in context: http://old.nabble.com/hbformat%2C-Where-is-the-error--tp26409889p26413489.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
[Harbour] GTwin console window
Ther'is a way to maximize the windows of a console application (GTwin)? I means no fullscreen mode, but resize avoiding any scrollbar. In my compiled app, the horizontal size don't match the 80 chars * charwidth pixel and is needed to click the maximize button on the titlebar to avoid the display of the horizontal scrollbar. Any hint? TIA Maurizio PS: BTW, i posted the same message on user forum, but results to be freezed. It's true? -- View this message in context: http://old.nabble.com/GTwin-console-window-tp26443609p26443609.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
Re: [Harbour] GTwin console window
Forget previous message... Found the -gui switch and solved the problem. Best regards. Maurizio Maurizio la Cecilia wrote: > > Thanks for the clarification. > Anyway, i tested the gtwvt approach and crashed in the double console > window problem. > Also compiling wvtext.prg in tests folder with the command: > hbmk2 wvtest.prg > gives me the same result. > The gtapi.txt in the doc folder gives some directive to avoid this empty > console window added, but i don't resolve to obtain the only wvt window be > displayed. > Sorry for my sure misunderstood. > Best regards. > Maurizio > > > Viktor Szakáts wrote: >> >>> Ther'is a way to maximize the windows of a console application (GTwin)? >>> I means no fullscreen mode, but resize avoiding any scrollbar. >>> In my compiled app, the horizontal size don't match the 80 chars * >>> charwidth >>> pixel and is needed to click the maximize button on the titlebar to >>> avoid >>> the display of the horizontal scrollbar. >>> Any hint? >> >> There is no programmatic way to control native win console window >> look/behavior besides setting the number of rows/cols of screen area. >> >> Solution: Use GTWVT. >> >> Brgds, >> Viktor >> >> ___ >> Harbour mailing list (attachment size limit: 40KB) >> Harbour@harbour-project.org >> http://lists.harbour-project.org/mailman/listinfo/harbour >> >> > > -- View this message in context: http://old.nabble.com/GTwin-console-window-tp26443609p26455796.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
Re: [Harbour] GTwin console window
Thanks for the clarification. Anyway, i tested the gtwvt approach and crashed in the double console window problem. Also compiling wvtext.prg in tests folder with the command: hbmk2 wvtest.prg gives me the same result. The gtapi.txt in the doc folder gives some directive to avoid this empty console window added, but i don't resolve to obtain the only wvt window be displayed. Sorry for my sure misunderstood. Best regards. Maurizio Viktor Szakáts wrote: > >> Ther'is a way to maximize the windows of a console application (GTwin)? >> I means no fullscreen mode, but resize avoiding any scrollbar. >> In my compiled app, the horizontal size don't match the 80 chars * >> charwidth >> pixel and is needed to click the maximize button on the titlebar to avoid >> the display of the horizontal scrollbar. >> Any hint? > > There is no programmatic way to control native win console window > look/behavior besides setting the number of rows/cols of screen area. > > Solution: Use GTWVT. > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/GTwin-console-window-tp26443609p26455726.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
R: [Harbour] Re: SF.net SVN: harbour-project:[12956] trunk/harbour
I confirm this behaviour. And i suggest also to take in count of the .INI files in the project structure, as could be useful to rebuild the app after a change in one of these files. xMate hitself has support for ini files, but don't includes this files in the search and replace function. I think that, because often the content of ini file is related to code, we could include also this type in selection of search and replace function. Thanks for the great work you're making, Pritpal. Best regards. Maurizio > -Messaggio originale- > Da: Angel Pais [mailto:amigo...@adinet.com.uy] > Inviato: sabato 21 novembre 2009 3.12 > A: harbour@harbour-project.org > Oggetto: [Harbour] Re: SF.net SVN: harbour-project:[12956] > trunk/harbour > > vouch...@users.sourceforge.net escribió: > > * contrib/hbide/hbide.prg > > + Implemented prototype of . > > Also play with various icons. Docks at the right and > at the bottom can be collapsed. > > Please forward suggesstions. > > Hi Pritpal > > I was playing with the new toy and noticed something weird: > > Open the app, then click on close button and everything is ok. > Open it again, then open hbide.prg with the source editor, close both > tabs and try to close the app. It freezes and has to be > killed with the > task manager. > > SO: win XP, harbour+mingw > > Regards > Angel > > > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[12965] trunk/harbour
Please, Viktor, add this line: METHOD GetDocumentProperties() INLINE win_GetDocumentProperties( ::PrinterName, @::FormType, @::Landscape, @::Copies, @::BinNumber, @::fDuplexType, @::fPrintQuality ) to win_prn class declaration as missed from source of Xavi. Best regards. Maurizio vszakats wrote: > > Revision: 12965 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=12965&view=rev > Author: vszakats > Date: 2009-11-21 23:02:42 + (Sat, 21 Nov 2009) > > Log Message: > --- > 2009-11-21 00:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbwin/win_prn2.c > ! Fixed PRINTEREXISTS() in UNICODE mode (hidden by wrong cast). > % Type cleanup (f.e. not using Windows type where not necessary). > % Cleaned away unnecessary casts. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/contrib/hbwin/win_prn2.c > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-12965--trunk-harbour-tp26461291p26461464.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
Re: [Harbour] SF.net SVN: harbour-project:[13291] trunk/harbour
Hi Pritpal, in MinGW build i receive this warning after a clean install make. ../../../../../bin/win/mingw/harbour.exe ../../../xbpwindow.prg -I../../../../.. /contrib/hbqt -i../../../../../include -n1 -q0 -w3 -es2 -kmo -i- -l ../../../xbpwindow.prg(785) Warning W0032 Variable 'LSUCCESS' is assigned but n ot used in function 'XBPWINDOW_DESTROY(0)' ../../../xbpwindow.prg(800) Warning W0032 Variable 'LSUCCESS' is assigned but n ot used in function 'XBPWINDOW_DISCONNECT(0)' Best regards. Maurizio la Cecilia vouchcac wrote: > > Revision: 13291 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13291&view=rev > Author: vouchcac > Date: 2009-12-18 09:46:11 + (Fri, 18 Dec 2009) > > Log Message: > --- > 2009-12-18 01:37 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbqt/hbqt.h > * contrib/hbqt/hbqt_base.cpp > * contrib/hbqt/hbqt_destruct.cpp > * contrib/hbqt/hbqt_events.cpp > * contrib/hbqt/hbqt_slots.cpp > > * contrib/hbxbp/xbpbrowse.prg > * contrib/hbxbp/xbphtmlviewer.prg > * contrib/hbxbp/xbpmenubar.prg > * contrib/hbxbp/xbpprinter.prg > * contrib/hbxbp/xbppushbutton.prg > * contrib/hbxbp/xbptoolbar.prg > * contrib/hbxbp/xbpwindow.prg > > * contrib/hbqt/tests/demoqt.prg > * contrib/hbide/hbide.prg > ! Cleaned up QT_PTROF() macro altogether. > A few instances are left in the HBXBP scheduled to be reviewed > later. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/contrib/hbide/hbide.prg > trunk/harbour/contrib/hbqt/hbqt.h > trunk/harbour/contrib/hbqt/hbqt_base.cpp > trunk/harbour/contrib/hbqt/hbqt_destruct.cpp > trunk/harbour/contrib/hbqt/hbqt_events.cpp > trunk/harbour/contrib/hbqt/hbqt_slots.cpp > trunk/harbour/contrib/hbqt/tests/demoqt.prg > trunk/harbour/contrib/hbxbp/xbpbrowse.prg > trunk/harbour/contrib/hbxbp/xbphtmlviewer.prg > trunk/harbour/contrib/hbxbp/xbpmenubar.prg > trunk/harbour/contrib/hbxbp/xbpprinter.prg > trunk/harbour/contrib/hbxbp/xbppushbutton.prg > trunk/harbour/contrib/hbxbp/xbptoolbar.prg > trunk/harbour/contrib/hbxbp/xbpwindow.prg > > > This was sent by the SourceForge.net collaborative development platform, > the world's largest Open Source development site. > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13291--trunk-harbour-tp26841838p26849378.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
[Harbour] hbide build problem
Surely, as usual, it's my problem... At link time quite all modules fails due to undefined reference to "_Unwind_Resume" and "__cxa_get_exception_ptr" and "__gxx_personality_v0". What i missed? TIA Maurizio -- View this message in context: http://old.nabble.com/hbide-build-problem-tp26958110p26958110.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
Re: [Harbour] hbide build problem
Ok. Worked fine pointing to mingw release embedded in the Qt installation. Better would be, IMHO, to specify in INSTALL that in compiling hbide the MinGW version needs to be the same as the Qt build. The "MinGW GNU C 3.4.2 and above" suggestion in INSTALL it's fine for Harbour build, but this it's no true for hbide. Thx for your aid. Maurizio Pritpal Bedi wrote: > > Hi > > > Maurizio la Cecilia wrote: >> >> Surely, as usual, it's my problem... >> At link time quite all modules fails due to undefined reference to >> "_Unwind_Resume" and "__cxa_get_exception_ptr" and >> "__gxx_personality_v0". >> What i missed? >> > > Install MINGW version pointed in INSTALL. > > Regards > Pritpal Bedi > > -- View this message in context: http://old.nabble.com/hbide-build-problem-tp26958110p26967929.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
Re: [Harbour] I migrated... thank you !
Hi Francesco, i'm glad to have contributed in orienting your choice to Harbour world and happy to have you in our community. Happy new year and good Harbour developing!!! Maurizio francesco perillo-2 wrote: > > I just want to tell you that last 28 Dec I finally migrated a company > from a clipper 5.01 to a Harbour 2.0 application suite... the first > migration commit in the applications VCS is dated december 2005... > they kept postponing but I finally forced them to switch and > everything went smooth... > > I want to say a big "THANK YOU" to all harbour developers for the > powerfull tool they built. I also want to publicy thank Maurizio for > the support and friendship he has given me in these months! > > Francesco > > HNYaaeeypprw I took the greetings from Ikea... now you have to > build it yourself > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://old.nabble.com/I-migrated...-thank-you-%21-tp26989771p26991820.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
Re: [Harbour] CDX RDD question (live usage/compatibility)
Sorry for reopening a very old and OT thread, but my needs are quite the same
as Viktor's one and i think something changed after 2005.
I ported successfully a large clipper 5.2e application, working on many
networks, to Harbour 2.0.
Now, before to swap the installation to Harbour version, i would to test the
effectiveness of the job using one or few Harbour workstation concurrently
with old Clipper ones on the same network.
Thus, i changed the Clipper app to use the DBFCDX driver and compiled
Harbour using the same driver and setting the locking scheme to CLIP (not
CLIP53). The adopted code is:
REQUEST DBFCDX
RDDSetDefault("DBFCDX")
RddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_CLIP )
REQUEST HB_LANG_IT
REQUEST HB_CODEPAGE_IT850
hb_cdpSelect('IT850')
hb_LangSelect('IT')
Apart of a dirty Clipper problem about the compound indexes (i posted
yesterday a message on the google clipper group) solved using the INDEX
command in place of the OrdCondSet()/OrdCreate() pair, the program crashes
only in one function, giving a "lock required" error after a successfully
lock of the same record. The strange thing is that the flow is apparently
the same of other parts of the application working fine.
Thus, i'm thinking that i gone wrong in some configuration option or i'm
ignoring some bug of the adopted implementation.
Ther'is any hint about the DBFCDX driver coexistence? Ther'is another better
path to try (not SQL based, as i need to mantain DBF approach before
quitting old Clipper world).
TIA.
Maurizio
Szakáts Viktor (Syenar) wrote:
>
> Hi all,
>
> Not strictly a developer question, but could anyone advise
> me, if the (x)Harbour CDX RDD is ready/recommended for
> heavy-duty live networked usage at the current stage?
>
> I'd like to put some Harbour compiled (win32) systems into
> live testing (first with 2-3 concurrent users), and I'd like to
> avoid database/index corruption.
>
> Is the locking method in (x)Harbour CDX compatible with
> CA-Clipper 5.2e? (I'm using SIXCDX actually)
>
> Any stories and opinions are very welcome.
>
> Brgds,
> Viktor
>
> PS: ADS is not an option for me.
> ___
> Harbour mailing list
> Harbour@harbour-project.org
> http://lists.harbour-project.org/mailman/listinfo/harbour
>
>
--
View this message in context:
http://old.nabble.com/CDX-RDD-question-%28live-usage-compatibility%29-tp990465p27305215.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
Re: [Harbour] CDX RDD question (live usage/compatibility)
I forgotten to say that the same piece of code works fine in Clipper
5.2e+DBFNTX and in Harbour+DBFCDX.
Maybe the opportunistic lock take a rule in that?
TIA.
Maurizio
Maurizio la Cecilia wrote:
>
> Sorry for reopening a very old and OT thread, but my needs are quite the
> same as Viktor's one and i think something changed after 2005.
>
> I ported successfully a large clipper 5.2e application, working on many
> networks, to Harbour 2.0.
> Now, before to swap the installation to Harbour version, i would to test
> the effectiveness of the job using one or few Harbour workstation
> concurrently with old Clipper ones on the same network.
>
> Thus, i changed the Clipper app to use the DBFCDX driver and compiled
> Harbour using the same driver and setting the locking scheme to CLIP (not
> CLIP53). The adopted code is:
>
>REQUEST DBFCDX
>RDDSetDefault("DBFCDX")
>RddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_CLIP )
>
>REQUEST HB_LANG_IT
>REQUEST HB_CODEPAGE_IT850
>hb_cdpSelect('IT850')
>hb_LangSelect('IT')
>
> Apart of a dirty Clipper problem about the compound indexes (i posted
> yesterday a message on the google clipper group) solved using the INDEX
> command in place of the OrdCondSet()/OrdCreate() pair, the program crashes
> only in one function, giving a "lock required" error after a successfully
> lock of the same record. The strange thing is that the flow is apparently
> the same of other parts of the application working fine.
>
> Thus, i'm thinking that i gone wrong in some configuration option or i'm
> ignoring some bug of the adopted implementation.
> Ther'is any hint about the DBFCDX driver coexistence? Ther'is another
> better path to try (not SQL based, as i need to mantain DBF approach
> before quitting old Clipper world).
> TIA.
> Maurizio
>
>
> Szakáts Viktor (Syenar) wrote:
>>
>> Hi all,
>>
>> Not strictly a developer question, but could anyone advise
>> me, if the (x)Harbour CDX RDD is ready/recommended for
>> heavy-duty live networked usage at the current stage?
>>
>> I'd like to put some Harbour compiled (win32) systems into
>> live testing (first with 2-3 concurrent users), and I'd like to
>> avoid database/index corruption.
>>
>> Is the locking method in (x)Harbour CDX compatible with
>> CA-Clipper 5.2e? (I'm using SIXCDX actually)
>>
>> Any stories and opinions are very welcome.
>>
>> Brgds,
>> Viktor
>>
>> PS: ADS is not an option for me.
>> ___
>> Harbour mailing list
>> Harbour@harbour-project.org
>> http://lists.harbour-project.org/mailman/listinfo/harbour
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/CDX-RDD-question-%28live-usage-compatibility%29-tp990465p27319051.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
R: [Harbour] CDX RDD question (live usage/compatibility)
> CL52 DBFCDX/SIX3 SIXCDX drivers are broken and can corrupt
> index files.
> so I cannot give you any guaranties that it will work. Anyhow if
> you want to use it and access the same index files by Harbour then
> you should use in Harbour SIXCDX RDD which tries to replicate some
> low level SIXCDX behavior. It creates less efficient indexes in some
> cases but it's a workaround for some CL52/SIXCDX bugs.
> CL53 DBFCDX/COMIX seems to be much better choice for Clipper.
Ok. I realize. No chance to recompile in Cl53, however, as i don't own it.
> Additionally you have to chose _EXACTLY_ the same locking schemes in
> both compilers.
> CL52 DBFCDX/SIXCDX uses FP locking. CL53 DBFCDX/COMIX use CL53 locking
> but it can be changed to FP locking if you link with your application
> cdxlock.obj
>
> >REQUEST DBFCDX
> >RDDSetDefault("DBFCDX")
> >RddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_CLIP )
>
> None of Clipper CDX drivers uses such locking scheme so it's wrong.
Ok. My mistake. I based my choice on xHarbour manual saying:
"Setting the locking scheme to 1 will lock the database files like
CA-Clipper 5.2 does. To use CA-Clipper 5.3's locking scheme, set
DBFLOCKSCHEME to 2. This will emulate shared locks using exclusive locks.
Visual FoxPro's locking scheme is selected with DBFLOCKSCHEME set to 3."
> If you are using HB_CODEPAGE_IT850 in Harbour then you have
> to link your
> Clipper application with ntxita.obj. Otherwise index files
> will be corrupted
> because Clipper and Harbour will use different collation orders.
I ever link ntxita.obj, also in DBFNTX build.
> Harbour and CL53 DBFCDX/COMIX do not support none compound IDX indexes
> so I guess you are using CL52 DBFCDX or SIXCDX driver.
Sorry, i was meaning production ".CDX" multitag indexes...
> In Clipper and Harbour 1022 "Lock required" RT error is logical error.
> It means that programmer didn't successfully locked the record. The
> physical record lock is not checked when this error is generated.
> It means that it's a problem with application code. Check why it's
> exploited when you compile it using Harbour. It's possible
> that setting
> valid locks scheme will hide the problem but for sure it will not fix
> the code. Such error should not appear in code which always checks
> results of RLOCK/FLOCK operations and never tries to write to
> not locked
> record so it's something what you should try to locate and
> fix in your code.
The problem is ONLY in Cl52+DBFCDX. With app built with Harbour or
Cl52+DBFNTX all works fine.
The Rlock() returns .t. in all the builded app, BUT ONLY in
Cl52+DBFCDX exits a "Lock required" error at subsequent field replace.
This happens also if the Cl52+DBFCDX is the ONLY program running on
the network...
So, i think that the problem is not deriving from my code... Same code
works fine in all other points of app updating a record.
> See above. You have to use exactly the same locking scheme
> and national
> sorting order inb both applications. If you are using CL52
> DBFCDX or SIXCDX
> then use in Harbour SIXCDX too. If you are using CL53 DBFCDX
> or COMIX them
> use in Harbour DBFCDX.
> CL52 DBFCDX and SIXCDX have serious bugs and for me should
> never be used
> in production environment. Anyhow it's possible that your
> code does not
> exploit them very often so you can live with it.
The feel i receive from your message is that i'm going in a puzzled
challenge, so i think i'll have two options:
A) To leave the Cl52+DBFNTX app, working well from twenty year ago, and
to change the driver of Harbour to DBFNTX
B) To take the courage of replace with Harbour+DBFCDX all the install
I don't know the effectiveness of the DBFNTX in Harbour, so i ask you
if also the A) choice is dangerous and the pure Harbour path is the only
affordable.
My great thanks for your support and precious feedback.
Best regards.
Maurizio
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] CDX RDD question (live usage/compatibility)
> -Messaggio originale- > Da: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl] > Inviato: martedì 26 gennaio 2010 20.05 > A: Harbour Project Main Developer List. > Oggetto: Re: R: [Harbour] CDX RDD question (live usage/compatibility) > > 1 works like CL52/CL53 DBFNTX if you do not link ntxlock.obj with > your code. Now it's clear. > The name is confusion. These .obj files change collation order in > Clipper VM and all index formats not omnly NTX. Yes. I know that. > > The feel i receive from your message is that i'm going in a puzzled > > challenge, so i think i'll have two options: > > A) To leave the Cl52+DBFNTX app, working well from twenty > year ago, and > >to change the driver of Harbour to DBFNTX > > It's possible. > > > B) To take the courage of replace with Harbour+DBFCDX all > the install > > It's probably safer method. > Anyhow as long as some network transport > layer does not cause some separate buffering which can cause problems > when DOS and Windows applications access files concurrently then it > should be safe to share database files and indexes between Clipper > and Harbour. It's enough to set compatible national sorting > and locking > schemes. > > > I don't know the effectiveness of the DBFNTX in Harbour, so > i ask you > > if also the A) choice is dangerous and the pure Harbour > path is the only > > affordable. > > In Harbour DBFNTX is probably much faster then in Clipper and for sure > they can be used to index realy big tables (I know that some people > use Harbour only to reindex files for Clipper due to huge > speed differnce > and the fact that over some size limits Clipper begins to GPF during > indexing). Harbour DBFNTX implementation also supports all > CDX extensions > and few others but you will not be able to enable all of them > if you want > to share data with Clipper. Compound index, large NTX file > support up to > 4TB or using RECNO as hidden part of index key to eliminate > linear scan > during record updating in indexes uses keys with big number > of repeated > values are extensions which change index formats and I > implemented them > only in Harbour and xHarbour so only in these languages can operate on > such NTX indexes. > Technically NTX format is much faster then CDX. In the ideal > environment > where you have a lot of RAM and you can keep index files in memory CDX > is many times slower then NTX. But we are not leaving in > ideal world and > in most of cases indexes are accessed using slow network connections. > It means that the size of index files will determinate the speed. CDX > files store keys in leaf nodes in compressed form what greatly reduces > the total index size and it's the reason of better overall performance > when the cost of reading/writing from/to index file is very big, i.e. > files are stored on file server. Your technical analysis is very useful and only now i realize that the NTX rdd is expanded in Harbour. A quick view on whatsnew.txt told me that was present yet in version 0.46. Anyway, the Harbour CDX install on all clients could be the safer choice, as you say. Again my great thanks for your support and kindness. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] hbpqtui class
>All users should see that the URL (f.e.: sf.net/harbour vs. sf.net/hbqt) >of a project (or library) won't make it less useful / sexy / used / >developed or less desirable. It stays the same project, with same >users and volunteer contributors. This is true, but... >In fact, in separate repositories it can even flourish better, >since there is no higher level or quality rules to adhere to, nor >getting an agreement from other project maintainers. This give >full freedom in the hands of developers. It also makes it that >everyone can much better concentrate on the area he is interested >in. Yes, but i was thinking that HBQT would become the "official" multiplatform GUI for Harbour >It also makes things to scale much better. >There are several good examples for this, in no particular order: >HWGUI, MINIGUI, WXHARBOUR, LETODB, XHGTK. Some of these wouldn't >be fit to Harbour SVN, because our stricter rules or portability >requirements. Yet they are useful, users keep using them, developers >keep developing them. Sometimes even Harbour developers are >participants in them. Hum, the freedom from stricter rules results in a bad integration with the main project. I come from the HwGUI experience, where only the effective work of Przemek allows to tune and clean many dirty or dubbed code. When i begun my interest in HwGUI, the Harbour build was lost because the active developers was interested mainly in xHarbour implementation. Just you, Viktor, signaled me the thing and i discouvered the great advantages of Harbour vs. xHarbour. >Being part of Harbour SVN is partly a deal: It has some benefits, >f.e. you get support and attention from core developers >(f.e. i've spent several weeks on HBQT altogether), you get quality >control, a build infrastructure, you have free packaging a release >"service", more attention, etc. Most of these require a significant >amount of time. So, in return IMO we rightfully expect for things >to be more or less inline with basic project goals and rules >and agreements. >It also seems a natural thing that components like _Harbour core_ >need much stricter quality control than upper level ones, since >everything is based on them, and this is the key to the stability of >the whole platform. While I personally believe that all components >should have equally good quality to form a good quality end result, >practice shows that this is sometimes not achievable in practice, >due to limited resource or not enough interest in this area, even >sometimes the time consumed would not be justified or even noticed >at the end. I can accept that. I agree with the standard good quality for all components (contribs included) of the project, at the cost of a slower but effective development. >At the end it comes out as: Is this deal worthwhile for all >parties? If it's a time wasting struggle for quality on one end, >and an uncomfortable feeling on the other end, what is the >point? Users won't benefit either, since developers are wasting >time instead of developing. >The other option is to lower quality needs, not think about >future, of redundancy of any form, priorities, or leaks, >allow GPFs and allow design decisions which will have such >a high "cost" in the future, that at that point nobody will >be able to deal with it anymore. See HBWHAT32 for an example >for that. >For a solution IMO we should seriously consider to split >Harbour into more parts, it has become huge and if this >continues it will become unmanageable and rather sooner or >later no quality can be guaranteed for some of its parts. >BTW, HBQT related parts now account for nearly HALF of the >size of all contribs. This is large. I don't want to think about the lack of collaboration between the main project and the HBQT... Just think to hbmk2 implementations to adhere to hbIDE needs... >I also think this community did it's job to help bring HBQT >+ parts to a nice, usable level now, and it can perfectly >stand on its own. Maybe HBQT by itself, if we stop to think to it as "official" GUI, but hbIDE project is very linked to main Harbour and HBQT, so a self growing and developing of HBQT could break the hbIDE work. >I'm glad to hear opinions on how to solve these in other ways. No opinions, but the feel that a contrib part of Harbour project MUST obey to general rules and follow the general architecture of the main project. So, IMHO, Pritpal could consider the opinion of Viktor as effective, mainly if thought to medium-large time, and i hope he will return to strict collaboration as we saw in the last days. Just my 1.5 cents... Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- View this message in context: http://old.nabble.com/hbpqtui-class-tp27332809p27343957.html Sent from the Harbour - Dev mailing list archive at Nabble
R: [Harbour] HB_BYTE vs. HB_UCHAR
I agree with the uniqueness of the type, but i like HB_UCHAR. The 'unsigned' qualifier is declared, despite of HB_BYTE (signed or unsigned?). I know that it's more familiar, but not so precise as the HB_UCHAR (leaving no doubt about the sign). Maurizio la Cecilia > -Messaggio originale- > Da: Viktor Szakáts [mailto:harbour...@syenar.hu] > Inviato: giovedì 11 febbraio 2010 15.07 > A: Harbour Project Main Developer List. > Oggetto: [Harbour] HB_BYTE vs. HB_UCHAR > > Hi Przemek and All, > > We have this decision left regarding new types, > and I'd like to clear it. > > We currently have two types which are mapped to > the same ANSI C type 'unsigned char'. > > IMO if we want to keep both, we should give some > clear guideline to Harbour and 3rd party developer, > as to which should be used in what situations. > > If we cannot do so, or if there is indeed no clear > different between them (meaning they are equivalent), > we should keep only one of them. In this case, > the question is which to keep. > > IMO we should keep HB_BYTE since it looks much more > familiar for users/developers and it's also much > older term in Harbour. > > Opinions are welcome. > > Brgds, > Viktor > > > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Lack of Bin2U in the last SVN trunk
After a clean rebuild of the current SVN version i can't no more link the Bin2U function. undefined reference to `HB_FUN_BIN2U' In effect, the function was disapparead in the rtl sources. Best regards. Maurizio la Cecilia -- View this message in context: http://old.nabble.com/Lack-of-Bin2U-in-the-last-SVN-trunk-tp27714124p27714124.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
Re: [Harbour] Lack of Bin2U in the last SVN trunk
I've found the Bin2U() function in the contrib\hbxpp\binnumx.c file. So, i realized that was treated as compatibility function. Please, ignore my prevfious message. Maurizio la Cecilia -- View this message in context: http://old.nabble.com/Lack-of-Bin2U-in-the-last-SVN-trunk-tp27714124p27714127.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
[Harbour] gtwvt compatibility issue
After this commit: 2010-02-22 20:43 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/gtwvt/gtwvt.h * src/rtl/gtwvt/gtwvt.c ! Fixed to use standard VGA RGB values, just like in GTXWC. ! Fixed color constant names (no "bright white" anymore). some numeric codes of color no more return the same color as the clipper or the harbour with the standard console gt driver. By example, the code 103 results different. I noticed that using the hb_DispBox() function. Best regards. Maurizio la Cecilia -- View this message in context: http://old.nabble.com/gtwvt-compatibility-issue-tp27714403p27714403.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
R: [Harbour] gtwvt compatibility issue
Hi Viktor,
I see it and this was the point of the fix, now the color
resembles to original Clipper color, which is "brown".
Now Harbour also shows brown in GTWVT, just like
in GTXWC and in Clipper on original MS-DOS, or on
emulators which properly mimic original colors.
In GTWIN and NTVDM, Microsoft chose to mess up the
colors, so you will see something different than MS-DOS.
(it's the kind of "gold", or it's rather "goose-sh*t green"
on my screen, definitely not brown)
So, I forgotten the Clipper-Dos colors, as in the last years
all my apps ran in the NTVDM window. It's true.
Anyhow you can change the default color mapping using
HB_GTINFO( HB_GTI_PALETTE, { ... } ) or
HB_GTINFO( HB_GTI_PALETTE, 6, 0x008585 )
Well. But, ther'is a doc about wvt? I'm catching the info from
"hbgtinfo.ch" and not all is very friendly.
[ This all applies only to GTWVT, you're
using a GTWVG header though in the example,
so please note that GTWVG has different colors,
and also the palette setting method is incompatible
with GTWVT. ]
Sorry, was a trash from a test i made to see if also wvg was affected
by the color change.
Best regards.
Maurizio
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: Anyone using hbqt ?
> francesco perillo wrote: > > > > Not only this little samples (I already wrote last week that little > > "dedicated" samples are better that a monolithic source full of > > everything... > > > > Probbaly some others should jump into this stream... I agree with Francesco. Also in HwGUI experience i found that a specific sample, exhausting the most important aspects of the class/function/argument is more productive. > You do not have to. > > Probably you missed some of the earlier commits. > Here is the reminder: > > 1. Open console from where you compile hbQT > 2. Goto harbour/contrib/hbqt/gtqtc > 3. Issue > make install > 4. If library is built, then, go to further deep in /tests > 5. Issue > hbmk2.exe demoqtc , and if .exe is generated > 6. Run > demoqtc > 7. Play with options and inspect the demoqtc.prg, it is pure > Clipper code. > > Though there are few glitches and still is not production level ready, > but amply demonstrate the potentials. I did not work on remaining > glitches as, at that point of time, I was not familiar with > Qt inside-out. > Now I am more equipped. If there is ample interest, and shown > on this also, > then I can look into GTQTC again. > Few time ago i inspetcted this contrib lib and found very interesting. I don't tried to use it because i thought was a sleeping project. Thus i'm sure very interested to a clipper based approach to Qt gui. > Soon, you will find, at least starting with, documentation. > Wait a few days more. Good news. Many thanks for the very effective work in hbide and Qt embedding. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: gtwvt compatibility issue
Not only GTWVG needs an update: a build with GTQTC showed me that the colors don't are coded in Clipper compatibility mode (as Viktor recent changed on WVT) and, mainly, many codepage and save/restscreen() problems. The box graphics and localized character, and the colors of saved/restored areas are buggy. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di Pritpal Bedi > Inviato: giovedì 25 febbraio 2010 17.22 > A: harbour@harbour-project.org > Oggetto: [Harbour] Re: gtwvt compatibility issue > > > > Viktor Szakáts wrote: > > > > I'm not 100% sure what you mean. The exact same > > code is used for HB_GTI_PALETTE handling in both GTs, > > except that GTWVG wasn't updated to use zero based > > color indexes, because it would have broken your local > > apps. > > > > Oh yep, now I remeber. > > You please fix the other part. I will look into it deeply > at a later date. Thanks for taking pain. > > > - > enjoy hbIDEing... > Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/gtwvt-compatibility-issue-tp4631971p4633464.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] Re: gtwvt compatibility issue
Ok. Thus the problems are known. I use obviously non-ASCII chars for boxes and accented italic chars and i can confirm many artifacts in general display of colors and restore of save screen areas. I can't, however, report about a so slow performance, appearing little slower of GTWVT solution but not dramatically. Anyway, having a GTQTC working could be a good bridge to port gradually a console application to hbqt, as Pritpal could allow the cohexistence of the two libs. I'm interested about the thought of Viktor and Pritpal about this. Best regards Maurizio _ Da: harbour-boun...@harbour-project.org [mailto:harbour-boun...@harbour-project.org] Per conto di Viktor Szakáts Inviato: domenica 28 febbraio 2010 16.27 A: Harbour Project Main Developer List. Oggetto: Re: R: [Harbour] Re: gtwvt compatibility issue Maurizio la Cecilia wrote: > > a build with GTQTC showed me that the colors > don't are coded in Clipper compatibility mode (as Viktor recent changed on > WVT) and, mainly, many codepage and save/restscreen() problems. > The box graphics and localized character, and the colors of saved/restored > areas are buggy. > Best regards. > I did not worked on GTQTC for a long time. Box characters were working perfectly, I will have to look what changes were made in the GT subsystem which I did not follow. Save/restore looks like broken now. Probably I have to use floating precision to calculate area position. Nothing changed AFAIK. Accented / non-ASCII chars never worked alright and there were several other screen artifact, performance was very slow and there were several basic problems with it (f.e. screen marking feature mixed up with mouse/key input). I reported some of these long ago. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] Re: gtwvt compatibility issue
Ok. Not necessarely GTQTC, but a chance to start with a working console based application and gradually mix pure GUI interface as HBQT. I don't was sure if this could be possible. I'll try to do. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di > Viktor Szakáts > Inviato: domenica 28 febbraio 2010 21.16 > A: Harbour Project Main Developer List. > Oggetto: Re: R: [Harbour] Re: gtwvt compatibility issue > > > Anyway, having a GTQTC working could be a good bridge to > port gradually a > > console application to hbqt, as Pritpal could allow the > cohexistence of the > > two libs. > > I'm interested about the thought of Viktor and Pritpal about this. > > IMO we should first try if it's possible to create mixed > GTWVT/GTXWC + HBQT applications. If this is possible, > there is just no need to put efforts into GTQTC. > > Since both HBQT and GT* are using simple GUI windows, > I can't see why there couldn't be both of them present in > the same app. > > Brgds, > Viktor > ___ > 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
R: R: [Harbour] Re: gtwvt compatibility issue
Good news. Thanks a lot. I'm waiting for wvtqt.prg sample, as i'm using GTWVT at this time. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di Pritpal Bedi > Inviato: domenica 28 febbraio 2010 22.15 > A: harbour@harbour-project.org > Oggetto: Re: R: [Harbour] Re: gtwvt compatibility issue > > > > Viktor Szakáts wrote: > > > >> Anyway, having a GTQTC working could be a good bridge to > port gradually a > >> console application to hbqt, as Pritpal could allow the > cohexistence of > >> the > >> two libs. > >> I'm interested about the thought of Viktor and Pritpal about this. > > > > IMO we should first try if it's possible to create mixed > > GTWVT/GTXWC + HBQT applications. If this is possible, > > there is just no need to put efforts into GTQTC. > > > > Since both HBQT and GT* are using simple GUI windows, > > I can't see why there couldn't be both of them present in > > the same app. > > > > GTWVT + HBQT ( alone or with hbXBP ) can coexits. No have > already showed it in demoqtc.prg in earlier days. Probably > I will commint one more wvtqt.prg soon. > > I donot know about GTXWC, however. > > GTWIN is absolutely out of question. > > GTWVT/GTWVG/(GTXWC ?) can have embedded QT GUI dialogs. > > > - > enjoy hbIDEing... > Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/gtwvt-compatibility-issue-tp4631971p4651003.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] hbIDE and Intellisense
Hi Pritpal, IMHO a xMate like support is needed and sufficient. The foundations are in the "intellihelp.txt" file of xMate, also displayable from xMate editor from menu item help->supplemental informations->intellihelp.txt Best regards and thanks for your strong work about hbQt and hbIDE. Maurizio la Cecilia > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di Pritpal Bedi > Inviato: lunedì 8 marzo 2010 3.43 > A: harbour@harbour-project.org > Oggetto: [Harbour] hbIDE and Intellisense > > > Hi All > > I am a step forward in basic constructs needed for > some "intellisense" concepts, but I am not sure what bunch > can be defined as intellisense. > > Can you post what is expected in a source editor in this > context. I do not want to build foundation which may require > deep changes in the future. > > Waiting to hear from you. > > > - > enjoy hbIDEing... > Pritpal Bedi > _a_student_of_software_analysis_&_design_ > -- > View this message in context: > http://n2.nabble.com/hbIDE-and-Intellisense-tp4693108p4693108.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] GTWVT and HB_INKEY_EXTENDED
I'm searching for a way to leave the standard Ctrl-C, Ctrl-X and Ctrl-V keys for triggering the clipboard features in my Harbour app using GTWVT as GT driver. The problem is that Ctrl-V has the same keycode of Ins key, interfering with the insert/overstrike mode toggle, and Ctlr-X has the same keycode of the down arrow key, interfering with the cursor down function. I used a workaround, enabling the HB_INKEY_EXTENDED mode in _SET_EVENT setting and changing the keycodes in getsys to hbinkey.ch. This way i could distinguish between Ins and Ctrl-V as scancodes are different and same could happen for Ctrl-X and CursorDown. Result: the Inkey() don't reacts to key presses and only Alt-C causes the exit from the application. Now i'm thinking that the HB_INKET_EXTENDED isn't supported by GTWVT driver. It's true or the problem is in other part of my implementation? TIA. Best regards. Maurizio la Cecilia ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] R: GTWVT and HB_INKEY_EXTENDED
I confirm same behaviour also using GTWIN as driver. So, could be my misunderstood in using extended keycodes? Maurizio la Cecilia > -Messaggio originale- > Da: Maurizio la Cecilia [mailto:m.laceci...@gmail.com] > Inviato: sabato 27 marzo 2010 0.15 > A: 'harbour@harbour-project.org' > Oggetto: GTWVT and HB_INKEY_EXTENDED > > I'm searching for a way to leave the standard Ctrl-C, Ctrl-X > and Ctrl-V keys for triggering the clipboard features in my > Harbour app using GTWVT as GT driver. > The problem is that Ctrl-V has the same keycode of Ins key, > interfering with the insert/overstrike mode toggle, and > Ctlr-X has the same keycode of the down arrow key, > interfering with the cursor down function. > > I used a workaround, enabling the HB_INKEY_EXTENDED mode in > _SET_EVENT setting and changing the keycodes in getsys to > hbinkey.ch. This way i could distinguish between Ins and > Ctrl-V as scancodes are different and same could happen for > Ctrl-X and CursorDown. > > Result: the Inkey() don't reacts to key presses and only > Alt-C causes the exit from the application. > Now i'm thinking that the HB_INKET_EXTENDED isn't supported > by GTWVT driver. > It's true or the problem is in other part of my implementation? > TIA. > Best regards. > > Maurizio la Cecilia > > ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] SF.net SVN: harbour-project:[14277] trunk/harbour
I receive a QT_STRONGFOCUS non existing variable running hbide, as in attached error message. Harbour SVN + Qt 2010.02.1 + MinGW TIA Maurizio la Cecilia > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di > vouch...@users.sourceforge.net > Inviato: mercoledì 7 aprile 2010 2.51 > A: harbour@harbour-project.org > Oggetto: [Harbour] SF.net SVN: harbour-project:[14277] trunk/harbour > > Revision: 14277 > > http://harbour-project.svn.sourceforge.net/harbour-project/?re > v=14277&view=rev > Author: vouchcac > Date: 2010-04-07 00:51:15 + (Wed, 07 Apr 2010) > > Log Message: > --- > 2010-04-06 17:40 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbqt/THbQtUI.prg > + Added more hbqt.ch defined constants. > > * contrib/hbide/resources/searchreplace.ui > * contrib/hbide/resources/searchreplace.uic > > * contrib/hbide/hbide.prg > * contrib/hbide/ideactions.prg > * contrib/hbide/idedocks.prg > * contrib/hbide/idefindreplace.prg > + Enabled again other way of "Search/Replace" invokable > by Ctrl+Sh+F. > This opens the dialog at the bottom of editing area. > This is exactly > the same as it is implemented in Qt Creator also. > > ! Fixed to always show up the right-dock widgets when invoked. > > Modified Paths: > -- > trunk/harbour/ChangeLog > trunk/harbour/contrib/hbide/hbide.prg > trunk/harbour/contrib/hbide/ideactions.prg > trunk/harbour/contrib/hbide/idedocks.prg > trunk/harbour/contrib/hbide/idefindreplace.prg > trunk/harbour/contrib/hbide/resources/searchreplace.ui > trunk/harbour/contrib/hbide/resources/searchreplace.uic > trunk/harbour/contrib/hbqt/THbQtUI.prg > > > This was sent by the SourceForge.net collaborative > development platform, the world's largest Open Source > development site. > ___ > 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
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
[Harbour] hbIde error selecting into output console window
Hi Pritpal, trying to select text into the output console window, on a line regarding a library error, this happens: a) an alert issue saying about the library: "File type unknown or not supported" b) hbIDE exits after displaying the attached error window. Ready to better specify if the context isn't clear. TIA. Maurizio la Cecilia <>___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: hbIde error selecting into output console window
Hi Pritpal, Here is it: http://www.mlacecilia.com/hbide_err.JPG Obviously, if i take to select starting outside the red error lines all works fine (same with "Select all" at right click). Since we are talking of this can you please also tell me why the function PrgVersion() results undefined in despite that is contained in main prg? Same sources compile fine in xMate. The others errors have reason to arise, but i don't understand why the symbol isn't resolved. TIA. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di Pritpal Bedi > Inviato: giovedì 8 aprile 2010 17.01 > A: harbour@harbour-project.org > Oggetto: [Harbour] Re: hbIde error selecting into output > console window > > > > Maurizio la Cecilia wrote: > > > > trying to select text into the output console window, on a > line regarding > > a > > library error, this happens: > > a) an alert issue saying about the library: "File type > unknown or not > > supported" > > b) hbIDE exits after displaying the attached error window. > > > > Ready to better specify if the context isn't clear. > > > > Show me the hbIDE's full screen shot when >>a) an alert issue saying about the library: "File type > unknown or not >>supported" > appears. > > > To copy the text from within Output Console, start it from some line > which does not have error information. > But I am interested more in under what circumstances and of what > type of error you are double-clicking. > > - > enjoy hbIDEing... > Pritpal Bedi > http://hbide.vouch.info/ > -- > View this message in context: > http://n2.nabble.com/hbIde-error-selecting-into-output-console > -window-tp4870734p4871639.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] Re: hbIde error selecting into output console window
> Just to confirm my beliefe, can you carry the same operations > after bringing > "Main" editors panel before carrying them ? > I will fix it in a while. > Sorry, but i'm not sure to have understood your request. I selected the edit panel and done same operation. I updated the screenshot at http://www.mlacecilia.com/hbide_err.JPG Now, after the error message, the GPF don't take place. Tell me if i'm wrong. Thanks. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: R: [Harbour] Re: hbIde error selecting into output consolewindow
> This is what I wanted to know, will fix shortly. > Thank you. Thank you for your courtesy and your effective work. I have minor suggestions: 1. I noticed that enabling the pages tab in the right panel, via menu or via toolbar it's the same, don't give focus to the page itself. Could be done? 2. Could be added the support also for non code files ( i.e.: .ini, .txt, .fwg, .xml, .customextension ) so they are stored in the project, are editable by the hbIDE editor and don't partecipate to the hbp build 3. If the point 2. is suitable, could be associated to the extension a command to execute on the files having that extension? I means same behaviour of the very good xDevStudio of Renato Vailton, allowing to launch a program/command/script applied to the list of files grouped by extension. 4. Could be added one slot for pre and post build? Most important the post build slot, as could allow additional jobs as constructing installer, posting on web the installer, etc. If something results cryptic on the use of those features ask me and i'll try to better explain what i'm meaning. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: R: R: R: [Harbour] Re: hbIde error selecting intooutputconsolewindow
> Which Harbour revision you are using. > It has already been fixed a couple of days before. > SVN 14292 2010-04-08 21:23 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) It's a Harbour problem? > Added .fmg. "Custome extension" wide opens the scope though I > will think. I'll use the available extensions. BTW, custom extension was my need because i use a selfmade repository of the application objects (in other words, a data driven engine) and i need to include into the project the files containing the objects descriptors, avoiding that hbIDE will compile it. I was ignoring that .xml, .ini and other extensions was yet managed by hbIDE, so the problem don't exists. > For this purpose you can use "Tools and Utilities" mechanism, > it exposes much powerful features. > > In practice, you never need to execute "post" actions with every > built. It is generally carried out once you are sure that > edit/compile/link > cycles are upto production level. So, in my opinion, it must remain > outside of the "build" process. You are right, in general way, but in my scenario could be fine if the repository builder will be activated at the end of the prg compile and before the exe is started, otherwise i'll have to do these steps: 1. compile the prg without launching the exe 2. launch my repository builder 3. launch the installer builder 4. upload to the web the installer 5. publish to the web the new version availability 6. launch the exe if needed A very time expensive job. Now i manage this in a single click with xMate, using the post build user command. In addition, xMate starts the command only if the main build ends successfully, so your doubts about to start user commands on inconsistent build are unapplicable. This was also because i asked for the association of extension with a command ( a la xDevStudio ), allowing that the builder will apply to proprietary resouce files based on extension. I realize it's my need, but could be an interesting feature is someone else have similar problem (xml is largely used in data driven applications). Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: R: R: R: R: [Harbour] Re: hbIde error selectingintooutputconsolewindow
> Is it not simpler to not limit extensions, just offer '*' / '*.*'? > > IMO, adding user or 3rd party (non-free) specific extensions > hard-wired into hbide (or any Harbour code) is very bad idea. > > Of course another more complicated way is to make this configurable > (f.e. via hbide.ini). > I agree. > AFAIR this has been implemented, and now you can call > 'hbide my.hbp' to launch a project. > > Adding necessary file type association is left as a job > for users, as it's highly platform dependent and some > users may not like such tampering in local environment. I'll investigate. Maybe the feature is yet available. Any clue about how to implement the file association? TIA Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: someone uses hbqt for "business" applications ?
> francesco perillo > Inviato: venerdì 23 aprile 2010 13.38 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Re: someone uses hbqt for "business" > applications ? > Personally, I did some tests in the past with hwgui and used the text > based coordinates as multipliers of font height and width... > WIDTH value can be calculated... code can be taken from the GET > system, since it calculates the screen area to use... just multiply by > font width.. I agree, but only if the coordinates are referred to the current form, and not to the absolute screen as i think Lorenzo was meaning. So, a great effort is needed to describe the widgets in form (and not screen) based coordinates, as you know i'm doing yet in Clipper apps. > PICTURE are a problem since there is non compatibility with Qt... I > don't use complex picture string, just some "@!"... > VALID and WHEN are a completely diffent subject since you have to > create a layer that handles object focus... more, I did not understand > if there is already a system (hbxbp???) to interface memory variables > with "widgets" > Example, setting a variable value inside a widget is "easy"... but > then the widget must set the new value back, possibly in a clipper > compatible way I think that hwGUI, hbXBP and other similar libraries Clipper/xBase/(x)Harbour based are more comfortable than the way hbQt could be linked to getsys construct, so a old Clipper application could be migrated with minimal or reasonable effort. > Or otherwise we should change programing paradigm, a new style of > programming, at least the screen interface... A long and winding road... Just you sent me an article about the risk of software rewriting from scratch... > > And what about tbrowses, achoices, prompts, > > menus? Another problem of QT is the SQL based approach of the browse/grid component. If you plain to retain the dbf paradigm i don't see any simple way to employ the Qt widgets for this objects. > In the long end, it would be difficult to adapt an old application > without serious changes in the code Well. If you mean to port an application from Clipper style to pure GUI style, i agree. The project hitself could become very different if you take full advantage of the graphics widgets and the UI approach can't be locked to the poor CUI interface. Anyway, if your target is to have the old Clipper application to run in a 32/64bit environment and in an acceptable graphic interface, the hwGUI & C. approach, IMHO, could be a very fast and non expensive path. Better would be to have an "official Harbour GUI", but this wish is very far from the target of Harbour developers, as stated in a quite old thread... So, hbQT will be the better choice to start a new project from scratch, but for me (and, I suspect, for us) at this time isn't very useful as i need to port old Clipper applications without loosing the logic and the affordabilty of the previous code. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: someone uses hbqt for "business" applications ?
Hi Pritpal and Francesco, as an old ( and not happy ) user of xBase++, I'm very interested to try the xBase parts in starting the second step of my migration path. I successfully migrated four consistent and working production applications in Harbour, using Wvt as GT, and easily I'll make same work for a lot of other applications running currently in Clipper 5.2e. Now, i need to change from CUI to GUI and, before to reapply my work and knolewdges in hwGUI, I'll try to use hbxbp for UI. I found, many years ago, very friendly the way how xBase Parts can integrate itself in a little modified version of getsys and my xBase port UI was very good. I abandoned xBase++ because I never obtained a fast and affordable database ( some critical error was inacceptable for production use ). If the compatibility with xBase Parts is full, I'll reuse the framework ( very similar to the layer used for hwGUI integration ) and i'll evaluate what library will be eligible for GUI migration. So, I ask you, Pritpal and Francesco, if you are interested to test this path. I can share my getsys layer ( Francesco yet knows how is built ) and we can use my working applications as effective test of migration. Question: hbxbp isn't a GT, so I figure that not will be possible to migrate incrementally the UI objects linking gtWvt+hbxbp... It's true? I'm waiting for you thought about. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di Pritpal Bedi > Inviato: sabato 24 aprile 2010 1.50 > A: harbour@harbour-project.org > Oggetto: [Harbour] Re: someone uses hbqt for "business" applications ? > > > > francesco perillo wrote: > > > > Pritpal, Bruno, Luciano, Maurizio, you all say interesting things... > > > > Let's try to go ahead step by step. > > > > < long message deleted to not be tedious... > > > > > I found the documentation for hbxbp (well, from the > original... :-) ) > > so I may try to start from there to create some simple > forms that > > feed my backend... Pritpal, is this the best way to use Qt ? > > > > Yes, to the best of my knowledge. > And if you count on me, I will surely provide whatever I > could on hbXBP > front. > I have made some fixes and more functionality in hbXBP and is > scheduled > to be committed tomorrow. > > The only problem till date is nobody has invested time > on writing a small application and then consistently pushing my > attention towards incompatibilities to be covered. > As I am a fan of Xbase++ class framework, but am not a > actual user, so all my own efforts are not enough. > Angel started but may be time constraints, he is not regular > on the subject, and you know, one looses zest when functional > results are not achieved. > > > - > enjoy hbIDEing... > Pritpal Bedi > http://hbide.vouch.info/ > -- > View this message in context: > http://harbour-devel.1590103.n2.nabble.com/someone-uses-hbqt-f > or-business-applications-tp4939610p4953269.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 mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: someone uses hbqt for "business" applications ?
> Lorenzo Fiorini > Inviato: sabato 24 aprile 2010 7.38 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Re: someone uses hbqt for "business" > applications ? > > On Fri, Apr 23, 2010 at 8:34 PM, Pritpal Bedi > wrote: > > I've nothing against hbqt. > The discussion is about using it to create business apps and I pointed > one problem: many here have a lot of C5x CUI code to convert and hbqt > does not help. I'm part of this people. hbQt could be the best choice due to his multiplatform, rich and well documented implementation, but the approach is very critical whan applied to existing Clipper code. > > > This is the main problem of > > every GUI library. We tend to forget the basic differences of > > CONSOLE and GUI way of programming flow - program controlled vs > > user controlled. We can mimic the CUI calls to present the interface > > but we _cannot_ mimic the CUI like behavior, viz., ReadModal(). > > Here I disagree. > > I have a Fivewin version of my apps since 1998 and I'm still selling > it. It has been relatively easy to reach the point where menus, forms > and tbrowses are "shared" between the CUI and GUI. Clearly it required > some classes, some PP and also some changes in the FW classes code but > since FW has SAY/GET and TCBROWSE classes it was not so hard. > > Result: I can build the same app as CUI or GUI simply defining a > __DOS__ or a __WIN__ macro at build time. > > The main point is that FiveWin was "planned" as a convertion tool for > C5x code while hbqt is a direct wrapper of C++ classes. > > IMHO hbqt needs a "compatibility layer" towards C5x UI components ( > and it can't be XBP for the reasons I already explained many times > before ). You are right. I agree with the "compatibility layer" as I used something similar to wrap hwGUI objects to my Clipper framework and worked fine. But I ask you for a reference to the thread about the XBP inconsistency in this approach, or a summary of your thought about. I'm very interested in use xBase Parts and, because I yet made a compatibility layer for xBase++, I would know what part of the layer could be critical in this approach whit Harbour. TIA. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Re: someone uses hbqt for "business" applications ?
> francesco perillo > Inviato: sabato 24 aprile 2010 8.52 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Re: someone uses hbqt for "business" > applications ? > > It is not its job ! > hbqt maps the Qt classes, and it's something we must have. Also > hwgui/minigui have such classes but in hwgui case (I didn't study > minigui code) they are a mess, since a class maps a windows objects > WITH clipper behaviour hbqt is better on this front, since a > QLineEdit works like a documented QLineEdit widget. And then you can > have hbxbp on top, that encapsulates QLineEdit in a xbpSLE, a bit > misleading name, but with written documentation and some sample code. > > > We can think about a "compatibility layer" and base it on hbxbp or > directly on hbqt... > I think better to go step by step. Only if we can obtain a working xbp layer, we'll can build a hbqt layer on it. The direct hbqt approach is very hard for me and could result in a no way direction. I'm ever targetting to port old Clipper code. Maybe if you unlink this need (as hbIDE project), starting from scratch could be useful in hbqt direct approach. > Me too, . But for example in CUI applications with no mouse enabled > you were forced to enter all the on-screen fields (*) so that you > could use VALID/WHEN for side-effects jobs like moving record > pointers, setting variables, etc. With the mouse, you can jump from > field to field... in windows users expect that disabled fields are > grayed (WHEN condition= false) and not just skipped so that you should > evalutate the conditions not just when entering the field (but it can > have side-effects...) > A layer taking count, in a little modifed getsys (mainly reader), could take in charge the event polling. You know how this was made in hwGUI approach and how this way we mimic the readmodal using graphic controls. > Is your code using @ GET, or is data-driven based ? In the first case > the only way to go is with PP (like Massimo has shown) and some glue > classes, in the second case it can be easier (can be, Maurizio warned > about possible coordinates problems) It's absolutely needed to link the coordinates of the controls to the current form and not to the screen. > We can think about a "compatibility layer" and base it on hbxbp or > directly on hbqt... I vote again for test before the hbxbp layer. I'm architect. Never build the upper floors on a unsure foundation. About the direct path i'm very dubious. > > I don't think it would be a hard job... hwgui already has > such layer... Yes. We knows that. Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Error unZipping a crypted archive
If I try to unZip a crypted zipped archive, a -102 ( UNZ_PARAMERROR ) is
returned.
I use hbmzip lib ( and obviously minizip lib, as I use last SVN version ).
I believe to pass the right parameters. What's wrong?
Below a self contained example.
Just strip out the password parameter and all works fine.
TIA.
Maurizio
PROCEDURE Main()
LOCAL hZip
LOCAL cFName := "\svn\harbour\ChangeLog"
LOCAL hUnZip
LOCAL nErr
hZip := HB_ZIPOPEN( cFName + ".zip" )
IF ! Empty( hZip )
HB_ZipStoreFile( hZip, cFName, , "AnyPassword" )
HB_ZIPCLOSE( hZip )
ENDIF
IF ! Empty( hUnzip := HB_UNZIPOPEN( cFName + ".zip" ) )
nErr := HB_UNZIPFILEFIRST( hUnzip )
DO WHILE nErr == 0
HB_UnzipFileInfo( hUnzip, @cFName )
IF ( nErr := HB_UnzipExtractCurrentFile( hUnzip, cFName +
"_unzipped", "AnyPassword" ) ) != 0
Alert( "Error " + hb_NToS( nErr ) )
ENDIF
nErr := HB_UNZIPFILENEXT( hUnzip )
ENDDO
HB_UNZIPCLOSE( hUnzip )
ENDIF
-
Best regards.
Maurizio la Cecilia
--
View this message in context:
http://old.nabble.com/Error-unZipping-a-crypted-archive-tp28364005p28364005.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
R: [Harbour] Error unZipping a crypted archive
The error is set in this piece of code (external\minizip\unzip.c):
extern int ZEXPORT unzOpenCurrentFile3 (unzFile file, int* method,
int* level, int raw, const char*
password)
{
int err;
uInt iSizeVar;
unz64_s* s;
file_in_zip64_read_info_s* pfile_in_zip_read_info;
ZPOS64_T offset_local_extrafield; /* offset of the local extra field */
uInt size_local_extrafield;/* size of the local extra field */
#ifndef NOUNCRYPT
char source[12];
#else
if (password != NULL)
return UNZ_PARAMERROR;
#endif
if (file==NULL)
return UNZ_PARAMERROR;
s=(unz64_s*)file;
if (!s->current_file_ok)
return UNZ_PARAMERROR;
The tests of correctness of file would be ininfluent, as the error is set
only when the password is supplied.
This seems to set the error any time a not empty password is supplied, if
NOUNCRYPT is defined.
But NOUNCRYPT would'nt be defined, so the thing would work as expected.
Maybe the NOUNCRYPY is unexpectedly set?
Just my thought. I'll try to set some tracepoint.
Best regards.
Maurizio la Cecilia
> -Messaggio originale-
> Da: harbour-boun...@harbour-project.org
> [mailto:harbour-boun...@harbour-project.org] Per conto di
> Viktor Szakáts
> Inviato: lunedì 26 aprile 2010 16.42
> A: Harbour Project Main Developer List.
> Oggetto: Re: [Harbour] Error unZipping a crypted archive
>
> Looks like the password is ignored when doing the compression.
>
> Viktor
>
> On 2010 Apr 26, at 14:53, Grigory Filatov wrote:
>
> >
> > Hello Maurizio,
> >
> > I confirm this problem with sample
> harbour\contrib\hbmzip\tests\myunzip.prg
> > also.
> >
> > myunzip myzip.zip --pass mypass
> >
> > Can somebody take a look for this issue?
> >
> > --
> > Regards,
> > Grigory Filatov
> >
> >
> > Maurizio la Cecilia wrote:
> >>
> >> If I try to unZip a crypted zipped archive, a -102 (
> UNZ_PARAMERROR ) is
> >> returned.
> >> I use hbmzip lib ( and obviously minizip lib, as I use
> last SVN version ).
> >>
> >> I believe to pass the right parameters. What's wrong?
> >> Below a self contained example.
> >> Just strip out the password parameter and all works fine.
> >> TIA.
> >> Maurizio
> >>
> >>
> >
> > --
> > View this message in context:
> http://old.nabble.com/Error-unZipping-a-crypted-archive-tp2836
> 4005p28364199.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
>
> ___
> 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] Error unZipping a crypted archive
Hi Viktor, the zipped file IS password encrypted. If you open it via an archive program the file is correct and the content can be extracted only suppling the correct password. The problem is on the unzip job. Best regards. Maurizio Viktor Szakáts wrote: > > Looks like the password is ignored when doing the compression. > > Viktor > > On 2010 Apr 26, at 14:53, Grigory Filatov wrote: > >> >> Hello Maurizio, >> >> I confirm this problem with sample >> harbour\contrib\hbmzip\tests\myunzip.prg >> also. >> >> myunzip myzip.zip --pass mypass >> >> Can somebody take a look for this issue? >> >> -- >> Regards, >> Grigory Filatov >> >> >> Maurizio la Cecilia wrote: >>> >>> If I try to unZip a crypted zipped archive, a -102 ( UNZ_PARAMERROR ) is >>> returned. >>> I use hbmzip lib ( and obviously minizip lib, as I use last SVN version >>> ). >>> >>> I believe to pass the right parameters. What's wrong? >>> Below a self contained example. >>> Just strip out the password parameter and all works fine. >>> TIA. >>> Maurizio >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/Error-unZipping-a-crypted-archive-tp28364005p28364199.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 > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > - Best regards. Maurizio la Cecilia -- View this message in context: http://old.nabble.com/Error-unZipping-a-crypted-archive-tp28364005p28368594.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
R: [Harbour] Error unZipping a crypted archive
Hi Viktor, many thanks. All works fine now. Best regards. Maurizio > -Messaggio originale- > Da: harbour-boun...@harbour-project.org > [mailto:harbour-boun...@harbour-project.org] Per conto di > Viktor Szakáts > Inviato: lunedì 26 aprile 2010 21.14 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Error unZipping a crypted archive > > Hi Maurizio, > > You're right. (I missed a '-' in my test cmdline) > > Please retest after my latest commit. > > Viktor > > On 2010 Apr 26, at 20:40, Maurizio la Cecilia wrote: > > > > > Hi Viktor, > > the zipped file IS password encrypted. > > If you open it via an archive program the file is correct > and the content > > can be extracted only suppling the correct password. > > The problem is on the unzip job. > > Best regards. > > Maurizio > > > > > > Viktor Szakáts wrote: > >> > >> Looks like the password is ignored when doing the compression. > >> > >> Viktor > >> > >> On 2010 Apr 26, at 14:53, Grigory Filatov wrote: > >> > >>> > >>> Hello Maurizio, > >>> > >>> I confirm this problem with sample > >>> harbour\contrib\hbmzip\tests\myunzip.prg > >>> also. > >>> > >>> myunzip myzip.zip --pass mypass > >>> > >>> Can somebody take a look for this issue? > >>> > >>> -- > >>> Regards, > >>> Grigory Filatov > >>> > >>> > >>> Maurizio la Cecilia wrote: > >>>> > >>>> If I try to unZip a crypted zipped archive, a -102 ( > UNZ_PARAMERROR ) is > >>>> returned. > >>>> I use hbmzip lib ( and obviously minizip lib, as I use > last SVN version > >>>> ). > >>>> > >>>> I believe to pass the right parameters. What's wrong? > >>>> Below a self contained example. > >>>> Just strip out the password parameter and all works fine. > >>>> TIA. > >>>> Maurizio > >>>> > >>>> > >>> > >>> -- > >>> View this message in context: > >>> > http://old.nabble.com/Error-unZipping-a-crypted-archive-tp2836 > 4005p28364199.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 > >> > >> ___ > >> Harbour mailing list (attachment size limit: 40KB) > >> Harbour@harbour-project.org > >> http://lists.harbour-project.org/mailman/listinfo/harbour > >> > >> > > > > > > - > > Best regards. > > Maurizio la Cecilia > > -- > > View this message in context: > http://old.nabble.com/Error-unZipping-a-crypted-archive-tp2836 > 4005p28368594.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 > > ___ > 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
[Harbour] Mingw compile error of last svn version in wvgsink
T': ../../wvgsink.c:530: error: `hSink' undeclared (first use in this function) ../../wvgsink.c:533: warning: implicit declaration of function `hb_oleParam' ../../wvgsink.c: In function `HB_FUN_WVG_AXSHUTDOWNCONNECTIONPOINT': ../../wvgsink.c:545: error: `pSink' undeclared (first use in this function) ../../wvgsink.c:545: error: syntax error before ')' token ../../wvgsink.c:549: error: invalid type argument of `->' ../../wvgsink.c:549: error: syntax error before "pSink" ../../wvgsink.c:550: error: invalid type argument of `->' ../../wvgsink.c:558: error: invalid type argument of `->' ../../wvgsink.c: In function `HB_FUN_WVG_AXGETCONTROL': ../../wvgsink.c:594: warning: implicit declaration of function `hb_oleSetError' ../../wvgsink.c:605: error: invalid type argument of `->' ../../wvgsink.c:605: error: called object is not a function ../../wvgsink.c:606: error: invalid type argument of `->' ../../wvgsink.c:608: warning: implicit declaration of function `hb_oleItemPut' ../../wvgsink.c:608: warning: passing arg 1 of `hb_itemReturnRelease' makes poin ter from integer without a cast ../../wvgsink.c: In function `HB_FUN_WVG_AXDOVERB': ../../wvgsink.c:634: error: invalid type argument of `->' ../../wvgsink.c:634: error: called object is not a function ../../wvgsink.c:639: error: invalid type argument of `->' ../../wvgsink.c:639: error: invalid operands to binary & ../../wvgsink.c:647: error: invalid type argument of `->' ../../wvgsink.c:647: error: syntax error before "hb_parni" mingw32-make[3]: *** [wvgsink.o] Error 1 mingw32-make[3]: Leaving directory `C:/CVS/harbour/contrib/gtwvg/win/mingw' mingw32-make[2]: *** [descend] Error 2 mingw32-make[2]: Leaving directory `C:/CVS/harbour/contrib/gtwvg' mingw32-make[1]: *** [gtwvg.inst] Error 2 mingw32-make[1]: Leaving directory `C:/CVS/harbour/contrib' mingw32-make: *** [contrib.inst] Error 2 GNU Make returned: 2 TIA. Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Mingw compile error of last svn version in wvgsink
Good catch, Viktor... Maybe some update from svn crashed sometime ago. Many thanks and best regards. Maurizio la Cecilia > -Messaggio originale- > Da: Viktor Szakáts [mailto:harbour...@syenar.hu] > Inviato: venerdì 19 giugno 2009 13.35 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Mingw compile error of last svn > version in wvgsink > > Hi Maurizio, > > Pls try after fresh checkout and clean build, probably some > wrong headers are being used. Here it's okay. > (except for one known warning in wvgsink.c) > > Brgds, > Viktor > > On 2009.06.19., at 13:20, Maurizio la Cecilia wrote: > > > This is the report that i obtain rebuilding harbour via "make_gnu > > install". > > > > Omissis > > > > mingw32-make[3]: Entering directory `C:/CVS/harbour/contrib/gtwvg/ > > win/mingw' > > gcc -I. -I../../../../include -Wall -W -O3 -fomit-frame-pointer - > > march=i586 > > -mt > > une=pentiumpro -I../../../../contrib/hbwin -c ../../gtwvg.c - > > ogtwvg.o gcc -I. -I../../../../include -Wall -W -O3 > > -fomit-frame-pointer - > > march=i586 > > -mt > > une=pentiumpro -I../../../../contrib/hbwin -c ../../wvgcore.c - > > owvgcore.o gcc -I. -I../../../../include -Wall -W -O3 > > -fomit-frame-pointer - > > march=i586 > > -mt > > une=pentiumpro -I../../../../contrib/hbwin -c ../../wvgutils.c > > -owvgutils.o gcc -I. -I../../../../include -Wall -W -O3 > > -fomit-frame-pointer - > > march=i586 > > -mt > > une=pentiumpro -I../../../../contrib/hbwin -c ../../wvgwin.c - > > owvgwin.o gcc -I. -I../../../../include -Wall -W -O3 > > -fomit-frame-pointer - > > march=i586 > > -mt > > une=pentiumpro -I../../../../contrib/hbwin -c ../../wvgsink.c - > > owvgsink.o > > ../../wvgsink.c:217: error: syntax error before "IConnectionPoint" > > ../../wvgsink.c:217: warning: no semicolon at end of struct or union > > ../../wvgsink.c:224: error: syntax error before '}' token > > ../../wvgsink.c:224: warning: type defaults to `int' in > declaration of > > `MyRealIE ventHandler' > > ../../wvgsink.c:224: warning: data definition has no type > or storage > > class > > ../../wvgsink.c: In function `QueryInterface': > > ../../wvgsink.c:238: warning: implicit declaration of function > > `HB_VTBL' > > ../../wvgsink.c:238: error: invalid type argument of `->' > > ../../wvgsink.c:238: warning: implicit declaration of function > > `HB_THIS' > > ../../wvgsink.c:248: error: invalid type argument of `->' > > ../../wvgsink.c:252: error: syntax error before ')' token > > ../../wvgsink.c:254: error: syntax error before ')' token > > ../../wvgsink.c:260: error: invalid type argument of `->' > > ../../wvgsink.c: In function `AddRef': > > ../../wvgsink.c:270: error: syntax error before ')' token > > ../../wvgsink.c: In function `Release': > > ../../wvgsink.c:280: error: syntax error before ')' token > > ../../wvgsink.c:282: error: syntax error before ')' token > > ../../wvgsink.c:283: error: syntax error before ')' token > > ../../wvgsink.c:285: error: syntax error before ')' token > > ../../wvgsink.c:291: error: syntax error before ')' token > > ../../wvgsink.c: In function `Invoke': > > ../../wvgsink.c:356: error: syntax error before ')' token > > ../../wvgsink.c:358: error: syntax error before ')' token > > ../../wvgsink.c:415: warning: implicit declaration of function > > `hb_oleItemToVari ant' > > ../../wvgsink.c: In function `SetupConnectionPoint': > > ../../wvgsink.c:451: error: `IConnectionPointContainer' undeclared > > (first use in this function) > > ../../wvgsink.c:451: error: (Each undeclared identifier is reported > > only once > > ../../wvgsink.c:451: error: for each function it appears in.) > > ../../wvgsink.c:451: error: `pIConnectionPointContainerTemp' > > undeclared > > (first u > > se in this function) > > ../../wvgsink.c:453: error: `IConnectionPoint' undeclared > (first use > > in this fun > > ction) > > ../../wvgsink.c:453: error: `m_pIConnectionPoint' undeclared (first > > use in this > > function) > > ../../wvgsink.c:454: error: `IEnumConnectionPoints' > undeclared (first > > use in thi s function) > > ../../wvgsink.c:454: error: `m_pIEnumConnectionPoints'
[Harbour] MinGW last cvs version compile error
Please, take count of this message: gcc -I. -I../../../../include -Wall -W -O3 -fomit-frame-pointer -march=i586 -mt une=pentiumpro-c ../../filesys.c -ofilesys.o ../../filesys.c: In function `hb_fsReadAt': ../../filesys.c:1698: error: `Flags' undeclared (first use in this function) ../../filesys.c:1698: error: (Each undeclared identifier is reported only once ../../filesys.c:1698: error: for each function it appears in.) ../../filesys.c: In function `hb_fsWriteAt': ../../filesys.c:1792: error: `Flags' undeclared (first use in this function) mingw32-make[3]: *** [filesys.o] Error 1 mingw32-make[3]: Leaving directory `c:/cvs/harbour/source/rtl/win/mingw' mingw32-make[2]: *** [descend] Error 2 mingw32-make[2]: Leaving directory `c:/cvs/harbour/source/rtl' mingw32-make[1]: *** [rtl.inst] Error 2 mingw32-make[1]: Leaving directory `c:/cvs/harbour/source' mingw32-make: *** [source.inst] Error 2 Harbour GNU Make returned: 2 Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] About hb_FEof()
I've found a problem due to the past name change of the hb_F_Eof() function in philes.c ( http://www.nabble.com/ChangeLog-2007-08-31-03%3A25-UTC%2B0200-Przemyslaw-Cze rpak-%28druzus-at-priv.onet.pl%29-tp12419138p12419138.html ), because the new hb_FEof() collides with the other one in hbmisc lib: libhbmisc.a:hb_f.o:04d0 T _HB_FUN_HB_FEOF libhbrtl.a:philes.o:0870 T _HB_FUN_HB_FEOF The double name, in effect, is still present in xHarbour, avoiding collisions when both libs are linked. I suppose the recent issue signaled ( http://www.nabble.com/libmisc.lib-hb_feof%28%29-always-.t.-tp17100490p171004 90.html ) is due to the wrong function called (the hbrtl one, instead of the hbmisc as expected). By the way, i think better to have a hb_F_Eof() in hbmisc and hb_FEof() in hbrtl, as the last is a more standard name for the function and the one in hbmisc is related to txt files only. Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] About hbextern...
Hum.. I think XML is the best format to use for this target. After a little effort in building and sharing an XSD schema, the contents can easily generate HTML, txt, PDF, docuwiki, etc. and are also ready to include in a dbms (not important if MySQL, DBF tables or other type). Just my 2 cents. Best regards. Maurizio la Cecilia Massimo Belgrano-3 wrote: > > instead organize in plain .txt i suggest organized in dbfMore easy to > organize,order,publish > is a clear demo of harbour capability > > 2009/7/8 Pritpal Bedi > >> >> Hello Vailton >> >> >> Vailton Renato wrote: >> > >> > There are a total of approximately 1600 functions. By my count if a >> > person is available to document at least 5 functions per day, he will >> > complete the service in less than 1 year. >> > >> > I was studying the issue of documentation and I thought of something >> > that I believe can help us. But it will take a few days to build a >> > structure that will create the documentation in those languages are >> > required and results can be published in HTML or PDF. >> > >> > >> > Anyway, I'm planning on testing it with our product here in Brazil and >> > then submit to you the results of my tests. >> > >> > If all goes well, I think we could use this solution to produce >> > documentation for our project. >> > >> > I can even help to produce the documentation in English, and obviously >> > I will need the help of everyone about questions and clarify some >> > details regarding functions, procedures and others. >> > >> > What the group thinks about this idea? >> > >> >> I was also thinking along this line and I already have some >> basic code to parse source tree ( provided by Andy Wos of xMate ). >> My intention was : >> >> 1) Parse the source tree, gather function arguments and return values >> 2) Organize them in plain .txt files with skeleton something like: >>FUNCTION: funcname() >>PARAMETERS: param1, param2, ... paramN >>RETURNS: xRet >>DESCRIPTION: >>EXAMPLE: >>SOURCE: >> 3) Place these skeletons in somewhere harbour/doc/skeletons/dirToRepsType >> 4) Request all group member to pick one,two or any number of functions >> he/whe is willing and fill in the blanjs >> 5) Place the filled in text in harbour/doc/worked/dirToRepsType >> 6) Request for volunteers to moderate those changes and make necessary >> changes >> 7) Build a compiled help from those filled-in skeltons. >> >> And may be more ideas which could flash at given moment. >> >> I was planning to do so after finishing HBXBP. It is nice to see that you >> have >> the same plans in mind. Please go ahead. >> >> Regards >> Pritpal Bedi >> >> >> -- >> View this message in context: >> http://www.nabble.com/About-hbextern...-tp24391919p24393130.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 >> > > > > -- > Massimo Belgrano > > ___ > Harbour mailing list > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > > -- View this message in context: http://www.nabble.com/About-hbextern...-tp24391919p24589659.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] About hb_FEof()
Hi Viktor, thanks for the very clear summary of the question. Sure my use of this functions is very basic (no MT, no heavy loops, etc.) and thus no problem arised here. I agree with your analisys and the definitve use of NF_F* in place of the hbmisc HB_F* functions, that could be dismissed. This could give back the HB_FEof() name to the rtl lib function, as is expected... I hope that someone will solve the lacks and the bugs of the NF set of functions as i find they are very useful and more complete than the hbmisc counterpart. Again my thanks. Maurizio la Cecilia Viktor Szakáts wrote: > > Hi Maurizio, > > Thanks for pointing it out. I've found this has a long history > in our ChangeLog. > > The hbmisc one is probably more often used despite being > part of one of the buggiest part of our codebase, and to be > honest for me the rtl HB_FEOF() function is also a very > strange beast (suboptimal to be called in loops and also > falls far from regular file handling scenarios.) In xhb HB_FEOF > means the hbmisc implementation. > > While for me it's also more natural to rename the hbmisc > one, it would also create more problems. Renaming the core > function is problematic because we should find a name > which describes functionality and adheres with core rules > (so here HB_F_EOF() isn't an option). I have no good > suggestion for another name, so either we should find > one or simply delete this function which I believe isn't > very useful nor it's used by too many users. > > As for the future and hbmisc: Since the HB_F*() functions > were simply copied from NF lib (also by changing the copyright > holder) and extended, but the still serve similar purpose, (and > similarl bugs, or even more), perhaps it would be nice to fix > the corresponding NF_F*() functions and offer them > as a replacement for current hbmisc functions. This way the > bugs would be solved, redundancy would be avoided, and > HB_ namespace usage in contrib would be avoided as well. > > This option of course needs someone who's willing to fix the > NF_F*()/HB_F*() code in the first place. Major problems with > it: integers type mess, non-MT compatible, not EOL neutral. > > Brgds, > Viktor > > On Tue, Jul 21, 2009 at 1:39 PM, Maurizio la > Cecilia wrote: >> I've found a problem due to the past name change of the hb_F_Eof() >> function >> in philes.c ( >> http://www.nabble.com/ChangeLog-2007-08-31-03%3A25-UTC%2B0200-Przemyslaw-Cze >> rpak-%28druzus-at-priv.onet.pl%29-tp12419138p12419138.html ), because the >> new hb_FEof() collides with the other one in hbmisc lib: >> >> libhbmisc.a:hb_f.o:04d0 T _HB_FUN_HB_FEOF >> libhbrtl.a:philes.o:0870 T _HB_FUN_HB_FEOF >> >> The double name, in effect, is still present in xHarbour, avoiding >> collisions when both libs are linked. >> I suppose the recent issue signaled ( >> http://www.nabble.com/libmisc.lib-hb_feof%28%29-always-.t.-tp17100490p171004 >> 90.html ) is due to the wrong function called (the hbrtl one, instead of >> the >> hbmisc as expected). >> By the way, i think better to have a hb_F_Eof() in hbmisc and hb_FEof() >> in >> hbrtl, as the last is a more standard name for the function and the one >> in >> hbmisc is related to txt files only. >> Best regards. >> >> Maurizio la Cecilia >> >> ___ >> 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 > > -- View this message in context: http://www.nabble.com/About-hb_FEof%28%29-tp24586108p24590500.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] Memory blocks not released
I'm investigating about a problem of Harbour CVS not releasing memory of unused modules. This happens constantly when a program linked with HwGUI opens and closes a dialog window (main windows not are affected). Same program compiled with last stable Harbour version releases correctly the memory. Maybe some memory management used by the destroy method of dialogs is wasted after the last MT changes. If i'll find some more precise info i'll tell ASAP. Note: to reproduce the error it's sufficient to build the \hwgui\samples\all\a.prg (with command: "bld a" executed form same folder of prg), but before is needed to add the line: Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] (no subject)
Sorry for the msg sent befor the completion This was the end of text: Note: to reproduce the error it's sufficient to build the \hwgui\samples\all\a.prg (with command: "bld a" executed form same folder of prg), but before is needed to add the line: SET( _SET_HBOUTLOG, somefilename, .t. ) at the start the prg and test how the output varies between cvs and stable version. Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Memory blocks not released
Sorry, forgot the previous message as was a HwGUI problem. I gone confused because the stable version don't signal this waste of memory (but still exists also in stable...). Thanks anyway. Maurizio -Messaggio originale- Da: Maurizio la Cecilia [mailto:[EMAIL PROTECTED] Inviato: sabato 25 ottobre 2008 19.29 A: harbour@harbour-project.org Oggetto: [Harbour] (no subject) Sorry for the msg sent befor the completion This was the end of text: Note: to reproduce the error it's sufficient to build the \hwgui\samples\all\a.prg (with command: "bld a" executed form same folder of prg), but before is needed to add the line: SET( _SET_HBOUTLOG, somefilename, .t. ) at the start the prg and test how the output varies between cvs and stable version. Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Which "standard" GUI for Harbour
Hi Lorenzo, > We are launching our new web site where we say "Terminal/GUI" but we > miss the ( full ) GUI part. > We can add a list of the several h*, x* and v* guis created so far for > Harbour but then we need to find answers to questions like "which is > the best?", "which one to choose?". > Clearly here the things become hard since we have both Linux and > Windows ( and few Mac ) users. > > Options: > > 1 - remove GUI from from the headlines and say "there are several GUIs > created..." > I think the better choice. > 2 - pick up one of the already existing ones and "promote it" as the > "default one" > None of the existing GUI can be elected to a "standard". A choice is very hard and will result to disagree the developers that don't use the elected one. > 3 - create a new GUI as we like > An effort with an interesting target, but not so simple to make. Is needed, as you say, a standard layer giving same interface in programming in all OSs and guaranting also that the identical result will be taken in each environment. In HwGUI, i.e., this isn't true even if a great effort was done to obtain an high degree of compatibility between WinAPI and GTK. Only a project giving strong headlines, including the type of implementation and clear rules for syntax and behaviour of the code, could interest the community of programmers currently developing GUI Libraries, otherwise each developer will continue to talk his dialect. The option 1, thus, is the quicker and not intrusive, but i hope that the option 3 could have a future. Best regards. Maurizio ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] Which "standard" GUI for Harbour
> What I meant was: > what we'll answer when a user will ask > "Which is the Harbour's GUI lib?" > > Also in Java there are Swing, SWT and many others but if you buy a > book about Java you'll find that Swing IS the Java GUI for desktop > apps. > Just this i was meaning. None of existing GUI can be thinked as THE Harbour GUI. I think that THE Harbour GUI would be OOP, multiplatform, well documented, well supported and in an active development and, mainly, aligned with the performances of Harbour and with the wishes of the Harbour developers. I don't see any OpenSource project having this characteristics, but only a lot of GUIs covering too few of this wanted features to be preferred on others. And i think that a GUI proposed by Harbour group as "official" could be only under GPL. > > A choice is very hard and will result to disagree the > developers that > > don't use the elected one. > > For elected I don't mean that everyone has to use it. > Simply that after saying "Harbour can create Terminal and GUI apps" we > need to add how it can do it. For terminals we've GT for GUI we have > ... and saying "there are a lot of them choose the one you like" is > good for skilled Harbour users but not for a new user that is > evaluating it. > Ok. Now the function of the "standard" GUI is clearer... An idea could be to have a demo, showing the common relevant features wanted by a GUI, builded with the best current libraries and self including the code needed to reach the functionality (a simple button "Show the code" triggering the listing of the current section). A not skilled Harbour developer could analyze the performances of the GUIs and the style and cost of coding, getting info about the library better matching his needs. > > In HwGUI, i.e., this isn't true even if a great effort was > done to obtain > > an high degree of compatibility between WinAPI and GTK. > > Only a project giving strong headlines, including the type of > > implementation and clear rules for syntax and behaviour of the code, > > could interest the community of programmers currently developing GUI > > Libraries, otherwise each developer will continue to talk > his dialect. > > This is why I think that xHGtk has more chances to survive than other > solutions. > Following closely Gtk standards they somewhat inherited the doc, the > tools and the "already proven" from it. But I agree with Viktor: OpenSource is a must, IMHO. > A complex GUI lib without a clean architecture, a tutorial and > complete doc is hard to pick up unless there is an existing code base > that require it. This is because i wrote "...but i hope that the option 3 could have a future". Best regards. Maurizio ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Make_b32 install?
I no longer obtain the command "make_b32 install" to work. Any hint? TIA Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] 2008-11-14 20:49 UTC+0100 Viktor Szakats
Hi Viktor. Thx. Fixed for me. Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] [hwguiwiki] - Wiki project about HwGUI
At the address http://hwgui.altervista.org you find a preliminary wiki site about HwGUI library. This is a project aiming to improve and update the documentation of the library, offering a complete reference guide, with sample usage, and other informations (how-to, faq, tools, usage patterns). The goal is to share the knowledge about HwGUI among programmers and to concentrate it in one repository open to everybody. Currently only one item is present in each section of classes, commands and functions reference. New items will be released in the next days, after collecting your suggestions. Any suggestion for improving this templates or for implementing the other areas currently not published wil be appreciated. If interested, look at home page for information on how to contact the wiki masters for starting a collaborative job. Regards. Maurizio la Cecilia Skype ID: m.lacecilia ICQ#: 233042955 Yahoo! ID: maurizio_lacecilia MSN id: mauriziolc ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HB_STATIC_FUNC
As posted on the hwGUI developers list on 13/04/2008 by Andi Jahja, ther'is a different implementation of static funcs at c level of harbour and xharbour. In harbour a similar declaration results in a HB_FUNC_EXTERN function with FS_PUBLIC scope and not in HB_FUNC_STATIC with FS_LOCAL scope. Maybe the current rearrangement of code in view of a new stable release could be a good time for analyzing this problem. In hwGUI development some weird coding is needed in mantaining source compatibility with either compilers. Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] HB_STATIC_FUNC
Hi Massimo, not at all. My target is strong encapsulation of data and methods in class implementation and i can obtain this, IMHO, only having in the same source the (x)harbour and C code. Otherwise the static function, i think obviously, will remain local to C module and cannot be reached by xBase code. In the hwgui CVS repository you can find source/hanimat.prg and take a look to what i'm meaning. This code works in xHarbour but in Harbour (stable version) don't resolves the HB_STATIC_FUNC correctly giving error at compile time. Best regards. Maurizio > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Per conto di > Massimo Belgrano > Inviato: giovedì 5 giugno 2008 23.54 > A: Harbour Project Main Developer List. > Oggetto: RE: [Harbour] HB_STATIC_FUNC > > Hi Maurizio > Your problem in hwgui will be resolved isolating c code in > external *.C ? > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Szakáts Viktor > Sent: Thursday, June 05, 2008 7:46 PM > To: Harbour Project Main Developer List. > Subject: Re: [Harbour] HB_STATIC_FUNC > > I'd add one more problem with INLINE C code: > > I extensively use grep for Harbour and my own projects > too, it's a very powerful tool to locate stuff in the > source. > > When I'm looking for C code parts (function names > let's say), naturally I search through *.c files only. > Problem: C code may be hiding inside .prg, too, or > even in .ch. This results in either wrong code updates, > decisions, or in the best, case another pass of grep. > > Not to mention all the tools which rightly except > some kind of content in a given file type (most > obvious example is syntax coloring). > > So this is IMO just one more thing that makes development > more complicated and error prone, without much gain. > > Brgds, > Viktor > > > ___ > 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
R: [Harbour] HB_STATIC_FUNC
Hi Viktor, > I see that even in hwgui, there are plenty of .c and > .prg files anyway, so I wonder why the mixed ones? > > One reason might be that this way, they can make > those C functions 'static' to the .prg file that uses > them (hence the recent question and all the hacking > to achieve this). To me this seems like something > which can be resolved using some internal namespaces, > or other logical distinction between published and > private API. All in all this is a fully regular problem, > present in all projects using more than one source > file, and everyone solves it without mixing. IMHO, i think that the solutions obtained without mixing prg and c code have as side effect that the function declared as static have still public scope and thus reachable by other modules of application. > BTW, hwgui main source folder has two hb_inline()s, > both seems easy to replace with one hb_bit*() call > each, plus there are a few files with BEGINDUMP, no > C code there has any special properties (and only some > of them are 'static') which would prevent moving them > into .c files, IMO. I had similar experience when porting > code with inline C from xhb to Harbour. In the hwgui CVS repository you can find source/hanimat.prg and take a look to what i'm meaning. This code works in xHarbour but in Harbour (stable version) don't resolves the HB_STATIC_FUNC correctly giving error at compile time. Avoiding the STATIC, the functions, also if present in the prg file, obviously become freely callable by other modules, and this is what i would to avoid. I think, after all, this is a real problem when is needed some C implementation AND encapsulation of class or standalone functions. Best regards. Maurizio ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] HB_STATIC_FUNC
Hi Przemek,
> > In harbour a similar declaration results in a
> HB_FUNC_EXTERN function with
> > FS_PUBLIC scope and not in HB_FUNC_STATIC with FS_LOCAL scope.
>
> Again it's not true.
I'm not so expert in prototyping, thus i could made some incorrect
assertion.
The true problem isn't probably in Harbour, but in Watcom/Harbour
compilation respect to Watcom/xHarbour one.
This is the Watcom/Harbour output:
...
Function Prototype:
HB_FUNC_EXTERN( ANIMATE_CREATE );
HB_FUNC_EXTERN( ANIMATE_OPEN );
HB_FUNC_EXTERN( ANIMATE_PLAY );
HB_FUNC_EXTERN( ANIMATE_SEEK );
HB_FUNC_EXTERN( ANIMATE_STOP );
HB_FUNC_EXTERN( ANIMATE_CLOSE );
...
Function body:
HB_FUNC_STATIC ( ANIMATE_CREATE )
HB_FUNC_STATIC ( ANIMATE_OPEN )
HB_FUNC_STATIC ( ANIMATE_PLAY )
HB_FUNC_STATIC ( ANIMATE_SEEK )
HB_FUNC_STATIC ( ANIMATE_STOP )
HB_FUNC_STATIC ( ANIMATE_CLOSE )
This is the output obtained using Bcc/xHarbour, but Andi Jahja reported this
worked also for Watcom/xHarbour.
HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_HANIMAT )
{ "HANIMATION_NEW", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_NEW )}, &ModuleFakeDyn },
{ "HANIMATION_ACTIVATE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_ACTIVATE )}, &ModuleFakeDyn },
{ "HANIMATION_INIT", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_INIT )}, &ModuleFakeDyn },
{ "HANIMATION_OPEN", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_OPEN )}, &ModuleFakeDyn },
{ "HANIMATION_PLAY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_PLAY )}, &ModuleFakeDyn },
{ "HANIMATION_SEEK", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_SEEK )}, &ModuleFakeDyn },
{ "HANIMATION_STOP", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_STOP )}, &ModuleFakeDyn },
{ "HANIMATION_CLOSE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_CLOSE )}, &ModuleFakeDyn },
{ "HANIMATION_DESTROY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_DESTROY )}, &ModuleFakeDyn },
.
Maybe this can better clarify what i was meaning.
> > In hwGUI development some weird coding is needed in
> mantaining source
> > compatibility with either compilers.
>
> For this problem the solution is very easy. Do not use:
>#pragma begindump
>
>#pragma enddump
> in .prg code.
If i don't do it, the symbol of C function become external and callable by
other modules of application and not only by the class prg code containing
the method.
Best regards.
Maurizio
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di
> Przemyslaw Czerpak
> Inviato: giovedì 5 giugno 2008 18.56
> A: Harbour Project Main Developer List.
> Oggetto: Re: [Harbour] HB_STATIC_FUNC
>
> On Thu, 05 Jun 2008, Maurizio la Cecilia wrote:
>
> Hi Maurizio,
>
> > As posted on the hwGUI developers list on 13/04/2008 by
> Andi Jahja, ther'is
> > a different implementation of static funcs at c level of harbour and
> > xharbour.
>
> It's not true.
>
> > In harbour a similar declaration results in a
> HB_FUNC_EXTERN function with
> > FS_PUBLIC scope and not in HB_FUNC_STATIC with FS_LOCAL scope.
>
> Again it's not true.
>
> > Maybe the current rearrangement of code in view of a new
> stable release
> > could be a good time for analyzing this problem.
>
> There is no problem in Harbour at all.
> The only one problem is in xHarbour which tries to analyze code
> inside:
>#pragma begindump
>
>#pragma enddump
> guessing it's valid C code to detect function declaration used inside.
> And of course it cannot work correctly without adding to xHarbour core
> code full functional C preprocessor plus code which will also
> parse all
> include .h files to make this C preprocessor working. This xHarbour
> feature have never worked so far for all valid C code and I do not see
> any way that it will ever be without investing time to write
> preprocessor
> which will be C compatible and adding to compilation process
> yet another
> pass which will preprocess .c file generated by Harbour with
> all included
> files (also with internal C compiler headers) to detect final
> compilation
> stream. Of course this C preprocessor should have all
> predefined values
> used later by C compiler and also respect local extenssions
> used by different
> C compilers so in practice it will have to be tuned for each
> compiler we
> are using. Do you believe it will be ever finished in
> xHarbour? I don't.
> Just check in generated .c files how xHarbour declares FUNC2() for
> code like:
>
>proc main()
> ? func1()
R: R: [Harbour] HB_STATIC_FUNC
> -Messaggio originale-
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di
> Szakáts Viktor
> Inviato: venerdì 6 giugno 2008 9.40
> A: Harbour Project Main Developer List.
> Oggetto: Re: R: [Harbour] HB_STATIC_FUNC
> Notice that amongst the 7 files using "inline" C,
> hanimat.prg is the only one actually using STATIC,
> and all those functions have distinct global names
> anyway, so IMO the whole problem is quite marginal
> and academic.
Not so, IMHO.
The Bcc/xHarbour resolves the function references in a local scope:
HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_HANIMAT )
{ "HANIMATION_NEW", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_NEW )}, &ModuleFakeDyn },
{ "HANIMATION_ACTIVATE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_ACTIVATE )}, &ModuleFakeDyn },
{ "HANIMATION_INIT", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_INIT )}, &ModuleFakeDyn },
{ "HANIMATION_OPEN", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_OPEN )}, &ModuleFakeDyn },
{ "HANIMATION_PLAY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_PLAY )}, &ModuleFakeDyn },
{ "HANIMATION_SEEK", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_SEEK )}, &ModuleFakeDyn },
{ "HANIMATION_STOP", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_STOP )}, &ModuleFakeDyn },
{ "HANIMATION_CLOSE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_CLOSE )}, &ModuleFakeDyn },
{ "HANIMATION_DESTROY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_DESTROY )}, &ModuleFakeDyn },
> The only "upside" is that you can work
> in one file instead of two when developing, but
> with the cost of creating non-portable code. I'm
> not sure if it's worth it.
The target isn't to work in a single class file, but in having API wrapper
functions not callable outside of a class.
> If speed is critical, or the whole functionality
> is in C anyway, you may also consider moving the
> whole class to C level. (errorapi.c is an example
> for such solution in Harbour).
Maybe this could be the better choice. I'll try it.
> But in the case
> of ANIMATE_*() I think it's by itself useful to
> have access to the API in a non-OOP way, too.
I don't agree.
The OOP way have sense just in a self contained implementation and
encapsulation of data and methods. What will happens if you write your own
CLASS_METHOD C function overloading the one declared at class declaration?
Why to make a OOP oriented GUI lib if you could make just a set of c wrapper
functions to API?
Maybe this is academic, but i've choosed hwGUI and not MiniGUI just for the
advantages and the features given by an OOP implementation.
Anyway, the truth is i can't to have a static C function be called by a
Harbour prg code and this, apart of academic talks, is a lack IMHO.
Best regards.
Maurizio
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: R: [Harbour] HB_STATIC_FUNC
Hi Victor, > From a purely practical POV regarding hwgui, the only > thing I don't see here is what makes ANIMATE > class so different from the other classes, that this > problem is present here, but not in other places. > Simply because this was first class in alphabetical order and when i started to make a wiki (hwgui.altervista.org) to give an updated reference guide on hwGUI i've analyzed his code. Other classes don't are affected just because after changing to static the class methods of hAnimate some signal of incompatibility with Watcom/Harbour was raised and i've stopped to implement static methods waiting for a solution, and stopped the documenting on wiki, because in doubt if also to reference the functions or avoid this. > Why hide them when they're ready and even useful? Only because i think that once create an object, to call directly his methods is ever the better and natural way of manage it. > But: In any case (for example if you don't want deal > with future compatibility for these functions), you can > name them __ANIMATE_*(), which will clearly show for > most ppl, that these are internal ones, and they better > not use them. > > Of course they are still not "forced" to not use them, > but since hwgui is an open source project, if someone > really wants to use them, they can simply remove the > static and still use them as is :) > > Also how would someone get to know about these functions > in the first place? 1) Documentation: don't include these > 2) sample code which uses internals: don't use them in > test code. 3) Peeking into source/.obj files (they can > do these anyways). > Yes, of course, i could hide something that could be hidden natively. If no solution will came i'll do so, or i'll use some #ifdef __XHARBOUR__ taking decision at compile time about the scope of methods. Not a problem at all. > The OOP implementation doesn't suffer in any case IMO. I agree, but anyway i still believe that would be better to can write some static C function (when speed is a must, by example) and can call hem from (x)harbour code without to make the function globally referenced. My signalation was just for asking to pay attention to this lack of feature during your renewed and effective effort about harbour. Thanks for your attention. Best regards. Maurizio ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: R: [Harbour] HB_STATIC_FUNC
Hi Massimo, > What do you think about using a robodoc for extract from source > Also here you see that separing prg and c will be more useful for > generating documentation I don't know this tools. I'll take a look. Also Francesco was interested to similar solution in aiding on documentation work. Thanks for the suggestion. Best regards. Maurizio ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Define for version recognition
I don't know if is possible, but i would know if ther'is in Harbour a pre defined constant telling at compile time what version (and hopefully subversion) of the compiler is in use. This could allow me to take care of features implemented in newer version and lacking in older version (the stable, by example...). TIA. Best regards. Maurizio la Cecilia ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Define for version recognition
Hi Viktor, to be clearer i'm searching something allowing a code as: #ifdef __HARBOUR__ #ifdef __HARBOUR_SVN__ Code with new feautured funcs #else Code with old fashioned funcs #endif #endif #ifdef __XHARBOUR__ #ifdef __XHARBOUR_CVS__ Code with new feautured funcs #else Code with old fashioned funcs #endif #endif or something doing the same job. You see, i need this flags at compile time ( of HwGUI, of course... ;) ), just for avoid to mantain compatibility with Harbour SVN only. Best regards. Maurizio > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Per conto di > Szakáts Viktor > Inviato: venerdì 27 giugno 2008 1.44 > A: Harbour Project Main Developer List. > Oggetto: Re: [Harbour] Define for version recognition > > Hi Maurizio, > > Pls check the version #defines in include/hbver.h, > on .prg level __HARBOUR__ has the version as its value. > > Brgds, > Viktor > > On 2008.06.26., at 19:19, Maurizio la Cecilia wrote: > > > I don't know if is possible, but i would know if ther'is in > Harbour > > a pre > > defined constant telling at compile time what version (and hopefully > > subversion) of the compiler is in use. > > This could allow me to take care of features implemented in newer > > version > > and lacking in older version (the stable, by example...). > > TIA. > > Best regards. > > Maurizio la Cecilia > > > > ___ > > 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 mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: [Harbour] Define for version recognition
Thanks Massimo. Luckly i've always used the __XHARBOUR__ before the __HARBOUR__ test (or only it) and the things have worked. Never thought __HARBOUR__ have same behaviour in both compilers... Now i stay tuned. Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Per conto di > Massimo Belgrano > Inviato: venerdì 27 giugno 2008 11.37 > A: Harbour Project Main Developer List. > Oggetto: RE: [Harbour] Define for version recognition > > #ifdef __HARBOUR__ > If return true in Harbour and xharbour! > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Maurizio la Cecilia > Sent: Friday, June 27, 2008 11:23 AM > To: 'Harbour Project Main Developer List.' > Subject: R: [Harbour] Define for version recognition > > Hi Viktor, to be clearer i'm searching something allowing a code as: > > #ifdef __HARBOUR__ > #ifdef __HARBOUR_SVN__ > Code with new feautured funcs > #else > Code with old fashioned funcs > #endif > #endif > > #ifdef __XHARBOUR__ > #ifdef __XHARBOUR_CVS__ > Code with new feautured funcs > #else > Code with old fashioned funcs > #endif > #endif > > or something doing the same job. > You see, i need this flags at compile time ( of HwGUI, of > course... ;) ), > just for avoid to mantain compatibility with Harbour SVN only. > Best regards. > Maurizio > > > > > -Messaggio originale- > > Da: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Per conto di > > Szakáts Viktor > > Inviato: venerdì 27 giugno 2008 1.44 > > A: Harbour Project Main Developer List. > > Oggetto: Re: [Harbour] Define for version recognition > > > > Hi Maurizio, > > > > Pls check the version #defines in include/hbver.h, > > on .prg level __HARBOUR__ has the version as its value. > > > > Brgds, > > Viktor > > > > On 2008.06.26., at 19:19, Maurizio la Cecilia wrote: > > > > > I don't know if is possible, but i would know if ther'is in > > Harbour > > > a pre > > > defined constant telling at compile time what version > (and hopefully > > > subversion) of the compiler is in use. > > > This could allow me to take care of features implemented > in newer > > > version > > > and lacking in older version (the stable, by example...). > > > TIA. > > > Best regards. > > > Maurizio la Cecilia > > > > > > ___ > > > 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 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 mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
R: R: [Harbour] Define for version recognition
Hi Viktor, this confirm what i'm making after the alert of Massimo. Luckly i've always used the __XHARBOUR__ before the __HARBOUR__ test and the things have worked. Never thought __HARBOUR__ have same behaviour in both compilers. Your arrangement allow to fine tune the source of HwGUI with newer feature more timely. My thanks for your courtesy and collaboration: same question posted to xHarbour group before this thread started never answered... Best regards. Maurizio la Cecilia > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Per conto di > Szakáts Viktor > Inviato: venerdì 27 giugno 2008 19.25 > A: Harbour Project Main Developer List. > Oggetto: Re: R: [Harbour] Define for version recognition > > > #ifdef __HARBOUR__ > > #ifdef __HARBOUR_SVN__ > > Code with new feautured funcs > > #else > > Code with old fashioned funcs > > #endif > > #endif > > > > #ifdef __XHARBOUR__ > > #ifdef __XHARBOUR_CVS__ > > Code with new feautured funcs > > #else > > Code with old fashioned funcs > > #endif > > #endif > > > With latest Harbour SVN: > > #ifdef __XHARBOUR__ > do xhb stuff, use xhb version defines. > #elif __HARBOUR__ > do Harbour stuff > /* supported method */ > #if __HARBOUR__ > 0x010100 > do some Harbour stuff available in or after version 1.1.0 > #endif > /* unsupported method. not recommended. >(since we might for example change to different repository > system in the future) */ > #if HB_VER_SVNID >= 8830 > do this way > #else > do that way > #endif > #endif > > Brgds, > Viktor > > ___ > 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
Re: [Harbour] Re: SF.net SVN: harbour-project:[14476] trunk/harbour
Il 16/05/2010 10.06, Viktor Szakáts ha scritto: I use vi (actually, vim) on both windows and linux... I used to use E2 (was it pe2??) I was given in 1987 by some programmers I met... it could do block copy/paste, I don't remember how but it could do... you could also select a box on the screen and then add borders... PE2 :) It was my first editor on a PC. And it was the last one I reconfigured the keys. PE2 was the first editor of quite all old programmers (me also), as sold by IBM at PC rise. I used it and abandoned it only when xMate offered me the features of a good project manager. I'm thinking that we are confusing some simple concepts. hbIDE started trying to emulate xMate as project manager hbmk2 based, AFAIR, so we need to distinguish between two aspects: the project manager itself and the editor (not talking about the formatter, the form generator, etc.). The editor, apart of few file functions (remove from, add to, rename, etc.) that are project related, is a very auto consistent part of xMate and could be fully replaced by any new solution accomplishing the needs of Harbor community, so my question is: could be better to allow to launch an external editor form hbIde? Just a provocation, as Harbour programmer's could obtain same productivity without to spend learning time. I think that the choice of emulating xMate was a very useful path to obtain a quick and effective skeleton and i think anyway that his editor it's no so bad at all. Only, it's has some non standard behaviour that could frustrate the programmers using other editors. This could have two aspects: 1. the natural reject of a new method to achieve same result in a new editor environment 2. some non optimal choice that xMate made in his behaviour About point 1, i think that some time needs to be spent to learn the new commands, as we made coming form Alt-B (on upper left corner) - Alt-B (on lower right corner) to select in PE2 a block to the Alt+(nouse/keyboard) selection of other "standard" editors (none talked about Notepad++, a very powerful one). So, if the xMate/hbIde well does the job i don't think that is needed to change something already working. About point 2 i agree with Viktor and Maniero when some command are requesting "innatural" actions or are cryptic (not in learning where are, but mainly in remembering how to use), so probably to adopt the "standard" method in this case is the better choice and also we, few but happy, users of xMate will enjoy this change. Actually PE2 still exists: http://www.pe32.com If xMate was allowing to launch an external editor, i never leaved PE2 approach. Mouse is a trap when you're writing code... Best regards. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extended .mem file handling
Il 17/05/2010 18.32, Viktor Szakáts ha scritto: An evolution library I was thinking to include it in hbvm, but for this it needs to be rewritten in .c and we need a new SET() (or similar) to enable the feature. Or it can be added as is as HB_MVSAVE() and HB_MVRESTORE() with somewhat friendlier (but compatible) parameter interface. Viktor I vote for hb_mv*() functions, so no loss of compatibility with old .mem files could happen. The new hb_mv*() funcs will be an "extended" Harbour version for mem files ( pardon, hbv files ) and any user will choose the type of management, mem (10 len) or hbv (>10 len). JM2C. Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] hbvpdf: how set the Page Size?
Il 22/05/2010 13.32, Jarosław Kądzioła ha scritto:
Hi,
function main()
local oPdf
oPdf := tPdf():New( 'test.pdf' )
oPdf:NewPage( "A4", "P", 6 )
oPdf:Center("Test")
oPdf:Close()
return nil
The "test.pdf" file has always the same size: 8,5 in. x 11 in., althoug
replacing "A4" by "LETTER", "A3"...etc
I'm using :
HPDF_Page_SetHeight()
HPDF_Page_SetWidth()
Hi, the question is about hbvpdf, not hbhpdf.
AFAIR hbvpdf don't cover the change of the page size, also if ther'is an
array storing the paper dimensions. Any change to the page type don't
results in a true recalculation of the layout.
I suggest to David, as Viktor saw to me, to use hbhpdf.
Best regards.
Maurizio
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
