[Harbour] BCC warnings with Rev. 13639
C++Builder 5.0 WinNT 4.0 ChangeLog 2010-01-18 17:52 UTC-0800 Pritpal Bedi (Rev. 13639) I get the following warnings: --- Warning W8004 ../../../ppcore.c 4273: 'szSwitch' is assigned a value that is never used in function hb_pp_processCondDefined Warning W8004 ../../../PPCORE.C 4273: 'szSwitch' is assigned a value that is never used in function hb_pp_processCondDefined Warning W8004 ../../../PPCORE.C 4273: 'szSwitch' is assigned a value that is never used in function hb_pp_processCondDefined Warning W8004 harboury.c 4048: 'yymsg' is assigned a value that is never used in function yydestruct Warning W8008 harboury.c 7052: Condition is always false in function hb_compparse Warning W8066 harboury.c 7053: Unreachable code in function hb_compparse Warning W8004 harboury.c 6980: 'hb_compnerrs' is assigned a value that is never used in function hb_compparse Warning W8004 harboury.c 4246: 'yyptr' is assigned a value that is never used in function hb_compparse --- Chen. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13639] trunk/harbour
Revision: 13639 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13639&view=rev Author: vouchcac Date: 2010-01-19 02:03:23 + (Tue, 19 Jan 2010) Log Message: --- 2010-01-18 17:52 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/hbqt_base.cpp * contrib/hbqt/hbqt_hbevents.cpp * contrib/hbqt/hbqt_hbslots.cpp ! HB_TRUE/FALSE <=> true/false. * contrib/hbide/hbide.prg * contrib/hbide/ideeditor.prg ! Updated to manage split windows properly. Presently the behavior is as such: Horizontal Split - Top row is columns are splitted Vertical Split - More row is added at the bottom. Delete Splitted Window - Focus is always shifted to main edit window. i.e., parent of all. Please comment. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbqt/hbqt_base.cpp trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp trunk/harbour/contrib/hbqt/hbqt_hbslots.cpp 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
Re: [Harbour] SF.net SVN: harbour-project:[13443] trunk/harbour
Hi, in a almost plain vanilla Debian Lenny doesn't run: Paquete: libqt4-dev Estado: instalado Instalado automáticamente: no Versión: 4.4.3-1 Prioridad: opcional Sección: libdevel Desarrollador: Debian Qt/KDE Maintainers Tamaño sin comprimir: 23,4M Depende de: libc6 (>= 2.7-1), libgcc1 (>= 1:4.1.1), libqt4-dbus (= 4.4.3-1), libqt4-qt3support (= 4.4.3-1), libqt4-xml (= 4.4.3-1), libqtcore4 (= 4.4.3-1), libqtgui4 (= 4.4.3-1), libstdc++6 (>= 4.1.1), zlib1g (>= 1:1.1.4), libqt4-network (= 4.4.3-1), libqt4-svg (= 4.4.3-1), libqt4-webkit (= 4.4.3-1), libqt4-sql (= 4.4.3-1), libqt4-script (= 4.4.3-1), libqt4-xmlpatterns (= 4.4.3-1), libqt4-designer (= 4.4.3-1), libqt4-help (= 4.4.3-1), libqt4-assistant (= 4.4.3-1), libqt4-test (= 4.4.3-1), qt4-qmake (= 4.4.3-1) Recomienda: libqt4-opengl-dev (= 4.4.3-1) Sugiere: qt4-dev-tools, qt4-doc, libmysqlclient15-dev, libsqlite0-dev, libsqlite3-dev, libpq-dev, libiodbc2-dev, firebird2.0-dev Tiene conflictos con: libqtwebkit-dev, qt3-dev-tools (<= 3:3.3.4-7) Reemplaza: libqt4-opengl-dev (< 4.4.0-2), libqtwebkit-dev Descripción: Qt 4 development files Qt is a cross-platform C++ application framework. Qt's primary feature is its rich set of widgets that provide standard GUI functionality. This package contains the header development files and development programs used for building Qt 4 applications. Página principal: http://www.trolltech.com 2010/1/3 > Revision: 13443 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13443&view=rev > Author: vszakats > Date: 2010-01-02 21:28:10 + (Sat, 02 Jan 2010) > > Log Message: > --- > 2010-01-02 22:26 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbqt/hbqt.h >+ Will now fail with forced compiler error if used with > QT libs older than 4.5.0. > > * package/winuni/mpkg_win_uni_extra_copy.bat >* Formatting. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbqt/hbqt.h >trunk/harbour/package/winuni/mpkg_win_uni_extra_copy.bat > > > 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 > -- Ing. Carlo Borelli Caracas, Venezuela Tel. +58 0412 6319387 / +58 0424 1990484 / +58 0212 5170479 Registered Linux User #249354 "Ad astra per aspera" ___ 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:[13632] trunk/harbour
Hi Przemek,
I understand these, but these are WinCE _OS_ calls,
not RTL ones, so even if they are present in some
buggy headers shipped with some compilers, the OS doesn't
provide them, regardless of compiler. (there may be
exceptions, but this should be clearly documented
f.e. in MS headers).
The only guard that exist in hbwince.c is HB_OS_WIN_CE,
(except for MulDiv, but this can be replaced by a
low-level Harbour function with different name), so
moving these to code is not something clumsy or horrible.
So overall, I don't really see the advantage of keeping
dummy stubs for them, now that only a few ones are left.
These are simple missing functions, and simply guarding
them makes it much more obvious that the functionality
is missing, and we also avoid any potential problems by
exporting functions with Windows API names. Some 3rd
parties may start to build on that, and it may also cause
collisions, none of them very good.
IMO, if we absolutely want to stick to keep this
special way of treating this regular problem, we at least
have to use distinctive names, and use PP macros to
map these to WinCE API names, f.e.:
BOOL WINAPI hbwince_LockFile( ... )
{
...
}
#ifdef WINCE [&& WHATEVER_COMPILER && WHATEVER_VERSION]
BOOL WINAPI hbwince_LockFile( ... );
#define Arc( ... ) hbwince_LockFile( ... )
#endif
This way the solution is much better controlled and
less "hidden", with less side-effects.
[ BTW this method is used by sqlite3. ]
Plus some of the not so often used stubs could easily
be dropped without major maintenance consequences.
(f.e. GDI ones).
Finally, contribs/3rd parties should never rely
on above "stub service" of Harbour core, to avoid
future problems. All of them should handle WinCE
missing functions on their own (preferably
by using portable Harbour core functions and adding
guards as needed)
How does this seem as a possible direction?
Brgds,
Viktor
On 2010 Jan 18, at 21:40, Przemysław Czerpak wrote:
> On Mon, 18 Jan 2010, Szak�ts Viktor wrote:
>> I understand this, but since in 95% of cases we're
>> doing well with simple #if guards, I'm not sure all
>> of these exceptions are valid one. F.e. the ones
>> I mentioned are solely used in GTWVT and GTWVG, pretty
>> easy to guard them, although f.e. in my mingw tests,
>> they worked well, so they seem to be supported.
>
> They are not supported by MinGWCE 0.55 I'm using in my
> Linux box though they exists in header files so code can
> be cleanly compiled. Fails when harbour.dll is created.
> Which version of MinGWCE do you use?
> 0.55 is the last official release. I've downloaded 0.59.1
> And checked that it also does not contain Arc(), FrameRect(),
> FloodFill(), MulDiv() and few others functions. But it has
> Beep() and file lock functions so I plan to enable then ASAP
> when I installed it and verify it with real compilation and
> link test. It will be nice if someone can also make runtime
> tests at least in some WinCE emulator.
> BTW I'm really happy that I have to update only single file
> instead of grepping the whole code and reverting hacks for
> functions missing in older MinGWCE versions and increasing
> number of #ifdef... conditions in core code. As long as we
> will not have new official release of MinGWCE I think it's
> good to keep support also for 0.55.
> I hope that someone can verify also MSVC and POCC WinCE builds.
>
>> Maybe it's not true for all old versions of all
>> compilers, but in this case it's still better to
>> fine-tune it with version guards.
>
> If these functions are missing only in WinCE RTL then guarding
> them in source code is IMO very bad and dirty solution which is
> also hard to update.
> It's much cleaner to add them in single file which is easy to
> update when new compiler is released and supports some additional
> functions. Otherwise we will left like in contrib where a lot of
> code which probably can be compiled for WinCE is simple disabled
> by !defined( HB_OS_WIN_CE ).
>
>>> BTW I also think that if some code can be compiled for WinCE and does
>>> not create some fixed dependencies which break existing functionality
>>> then we should compile it. I.e. with some minor fixes win_prn[123].c
>>> can be compiled for WinCE by MinGWCE. In current version of WinCE RTL
>>> low level functions do not exists but maybe they will be supported in
>>> the future or even by some 3-rd party extensions i.e. there is 3-rd
>>> party windows console for WinCE so it should be possible to use GTWIN
>>> with it so we can provide GTWIN for WinCE builds but of course it cannot
>>> be included in harbour.dll. Please also remember that new MinGW compilers
>>> support direct linking with .dll libraries and do not need any
>>> intermediate import libraries (BTW it's even suggested to eliminate
>>> import libraries from new projects because direct linking with .DLLs
>>> is faster and consumes less memory) so it's enough that user has valid
>>> .dlls to link his application
[Harbour] SF.net SVN: harbour-project:[13638] trunk/harbour
Revision: 13638 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13638&view=rev Author: vszakats Date: 2010-01-18 23:41:57 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-19 00:40 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/rtl/gtwvt/gtwvt.c * contrib/gtwvg/gtwvg.c ! Fixed GFX drawing functions to forward success/failure results from Windows API calls. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/src/rtl/gtwvt/gtwvt.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
Re: [Harbour] SF.net SVN: harbour-project:[13632] trunk/harbour
On Mon, 18 Jan 2010, Szak�ts Viktor wrote: > I understand this, but since in 95% of cases we're > doing well with simple #if guards, I'm not sure all > of these exceptions are valid one. F.e. the ones > I mentioned are solely used in GTWVT and GTWVG, pretty > easy to guard them, although f.e. in my mingw tests, > they worked well, so they seem to be supported. They are not supported by MinGWCE 0.55 I'm using in my Linux box though they exists in header files so code can be cleanly compiled. Fails when harbour.dll is created. Which version of MinGWCE do you use? 0.55 is the last official release. I've downloaded 0.59.1 And checked that it also does not contain Arc(), FrameRect(), FloodFill(), MulDiv() and few others functions. But it has Beep() and file lock functions so I plan to enable then ASAP when I installed it and verify it with real compilation and link test. It will be nice if someone can also make runtime tests at least in some WinCE emulator. BTW I'm really happy that I have to update only single file instead of grepping the whole code and reverting hacks for functions missing in older MinGWCE versions and increasing number of #ifdef... conditions in core code. As long as we will not have new official release of MinGWCE I think it's good to keep support also for 0.55. I hope that someone can verify also MSVC and POCC WinCE builds. > Maybe it's not true for all old versions of all > compilers, but in this case it's still better to > fine-tune it with version guards. If these functions are missing only in WinCE RTL then guarding them in source code is IMO very bad and dirty solution which is also hard to update. It's much cleaner to add them in single file which is easy to update when new compiler is released and supports some additional functions. Otherwise we will left like in contrib where a lot of code which probably can be compiled for WinCE is simple disabled by !defined( HB_OS_WIN_CE ). > > BTW I also think that if some code can be compiled for WinCE and does > > not create some fixed dependencies which break existing functionality > > then we should compile it. I.e. with some minor fixes win_prn[123].c > > can be compiled for WinCE by MinGWCE. In current version of WinCE RTL > > low level functions do not exists but maybe they will be supported in > > the future or even by some 3-rd party extensions i.e. there is 3-rd > > party windows console for WinCE so it should be possible to use GTWIN > > with it so we can provide GTWIN for WinCE builds but of course it cannot > > be included in harbour.dll. Please also remember that new MinGW compilers > > support direct linking with .dll libraries and do not need any > > intermediate import libraries (BTW it's even suggested to eliminate > > import libraries from new projects because direct linking with .DLLs > > is faster and consumes less memory) so it's enough that user has valid > > .dlls to link his application and use new functionality. > > So what should be the final conclusion here? > I'd personally simply remove those few GDI > WinCE stubs, as they seem to be supported and > wait for feedback where they exactly fail. > (f.e. I can't test msvcarm). They are not supported by MinGWCE 0.55 and MinGWCE 0.59.1 > As for the rest, I don't know, we may leave > them, but it would seem much cleaner and uniform > to add guards to them, where they are used. I do not find anything clean in hacking core code adding workarounds for missing functionality in some chose compiler versions. IMO it's much cleaner to keep all such hack in one place only and for sure it's much easier to update only single file and instead of introducing and reverting hacks in many different files. > I somehow feel it very uncomfortable to publish > system function form our own libs, be it .dlls > or static libs. Me two but it's minor problem in comparison to adding: #if !defined( HB_OS_WIN_CE ) || \ ( defined( __MINGWCE__ ) && __MINGWCE__ >= ... ) || ( defined( _MSC_VER ) && _MSC_VER >= ... ) || ( defined( __POCC__ ) && __POCC__ >= ... ) || [...] in many different places and then updating each of them when new compiler is released. I simply do not have time for it and I do not believe that will be updated by others. One file I can update from time to time very easy. Additionally I have documented in one place all missing functions so I can immediately locate what may be wrong when user reports some strange behavior. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Res: [Harbour] SET PRINTER TO
great, i´ll report this i´ll try Thanks, Fernando De: Viktor Szakáts Para: Harbour Project Main Developer List. Enviadas: Segunda-feira, 18 de Janeiro de 2010 11:44:40 Assunto: [Harbour] SET PRINTER TO Hi All, Above extension works in xhb but is not supported in Harbour. Actually for good reason, so my intent is not to propose it for inclusion, but I still wonder what is the easiest way (least code change) to achieve the same result in Harbour. [ NOTICE: This feature can only work if printer controls codes match those supported by the printer, and it's easily possible the printer doesn't support raw input _at all_. Plus it makes SET PRINTER TO incompatible. ] --- SET PRINTER TO ( win_PrinterGetDefault() ) ... SET PRINTER TO --- is equivalent to something like this in Harbour: --- [untested] LOCAL cTempName FClose( hb_FTempCreateEx( @cTempName ) ) SET PRINTER TO ( cTempName ) ... SET PRINTER TO win_PrintFileRaw( win_PrinterGetDefault(), cTempName ) FErase( cTempName ) --- Anyhow, this is my suggestion to xhb users wanting to switch to Harbour. If you know a better way, pls speak up. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.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:[13632] trunk/harbour
WIch version of mingw have this capability (direct linking with .DLL)? I remember a post (pritpal??) where mingw lack on microsoft visual c++ on follow point dll integration,Multiple resource file rc 2010/1/18 Przemysław Czerpak > Please also remember that new MinGW compilers > support direct linking with .dll libraries and do not need any > intermediate import libraries (BTW it's even suggested to eliminate > import libraries from new projects because direct linking with .DLLs > is faster and consumes less memory) so it's enough that user has valid > .dlls to link his application and use new functionality. > > best regards, > Przemek > > -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13637] trunk/harbour
Revision: 13637 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13637&view=rev Author: vszakats Date: 2010-01-18 19:37:26 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 20:32 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/vm/extrap.c * src/rtl/diskspac.c * src/rtl/disksphb.c * src/rtl/gtwvt/gtwvt.c * contrib/gtwvg/gtwvg.c * contrib/gtwvg/wvgwin.c * contrib/hbwin/win_prn2.c * contrib/hbwin/win_prn3.c + Using HBTEXT() macro on 2nd parameter of GetProcAddress() in _all_ cases. This can't hurt, but it's useful to never forget it for WinCE targets/branches. Recent change got also simplified after this. Pls review me. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/gtwvg/gtwvg.c trunk/harbour/contrib/gtwvg/wvgwin.c trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/contrib/hbwin/win_prn3.c trunk/harbour/src/rtl/diskspac.c trunk/harbour/src/rtl/disksphb.c trunk/harbour/src/rtl/gtwvt/gtwvt.c trunk/harbour/src/vm/extrap.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
Re: [Harbour] SF.net SVN: harbour-project:[13632] trunk/harbour
> On Mon, 18 Jan 2010, Szak�ts Viktor wrote: >> Is there any particular reason to define stubs >> for non-WinCE winapi calls in hbwince.c, like >> Ellipse(), Arc(), FrameRect(), FloodFill(), >> FreeResource()? >> Looks like these could be simply handled by >> HB_OS_WIN_CE guards, just like we do for all >> other similar case. > > 1. It's necessary to update code in many different places and > in some cases it makes code really unreadable > 2. I do not know which missing functions are real WinCE limitation > and which one are missing only in provided WinCE RTL, i.e. each > new release of MinGWCE adds new functions. It's much easier to > update single file then scan whole code for different: > #if ! defined( HB_OS_WIN_CE ) || ... > Please note that in few cases these are very important functions, > i.e. without file lock functions any WinCE application cannot access > concurrently the same DBF files. > 3. We added functions to emulate environment. We can also add functions > to emulate some other things like current directory and in such case > it's good to keep the same code for desktop windows and WinCE. I understand this, but since in 95% of cases we're doing well with simple #if guards, I'm not sure all of these exceptions are valid one. F.e. the ones I mentioned are solely used in GTWVT and GTWVG, pretty easy to guard them, although f.e. in my mingw tests, they worked well, so they seem to be supported. Maybe it's not true for all old versions of all compilers, but in this case it's still better to fine-tune it with version guards. > BTW I also think that if some code can be compiled for WinCE and does > not create some fixed dependencies which break existing functionality > then we should compile it. I.e. with some minor fixes win_prn[123].c > can be compiled for WinCE by MinGWCE. In current version of WinCE RTL > low level functions do not exists but maybe they will be supported in > the future or even by some 3-rd party extensions i.e. there is 3-rd > party windows console for WinCE so it should be possible to use GTWIN > with it so we can provide GTWIN for WinCE builds but of course it cannot > be included in harbour.dll. Please also remember that new MinGW compilers > support direct linking with .dll libraries and do not need any > intermediate import libraries (BTW it's even suggested to eliminate > import libraries from new projects because direct linking with .DLLs > is faster and consumes less memory) so it's enough that user has valid > .dlls to link his application and use new functionality. So what should be the final conclusion here? I'd personally simply remove those few GDI WinCE stubs, as they seem to be supported and wait for feedback where they exactly fail. (f.e. I can't test msvcarm). As for the rest, I don't know, we may leave them, but it would seem much cleaner and uniform to add guards to them, where they are used. I somehow feel it very uncomfortable to publish system function form our own libs, be it .dlls or static libs. Brgds, Viktor ___ 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:[13635] trunk/harbour
> On Mon, 18 Jan 2010, vszak...@users.sourceforge.net wrote: >> 2010-01-18 19:57 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) >> * src/common/hbwince.c >>- Deleted definition of FreeResource(). It's noe used anywhere >> in Harbour, and its declaration was also missing. > > See contrib/gtwvg/wvgcore.c[182] Yes, but it's guarded with ! HB_OS_WIN_CE, but it's not core Harbour's job to offer platform/compiler replacement functions for contib libs or 3rd party libs. We just bend the existing environment, and this is not good on the mid run. Such stuff should be done locally in each lib using guards. Brgds, Viktor ___ 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:[13635] trunk/harbour
On Mon, 18 Jan 2010, vszak...@users.sourceforge.net wrote: > 2010-01-18 19:57 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * src/common/hbwince.c > - Deleted definition of FreeResource(). It's noe used anywhere > in Harbour, and its declaration was also missing. See contrib/gtwvg/wvgcore.c[182] best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13636] trunk/harbour
Revision: 13636 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13636&view=rev Author: druzus Date: 2010-01-18 19:09:05 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 20:08 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/hbwin/win_tprn.prg ! fixed GetDefaultPrinter() => win_PrinterGetDefault() * harbour/contrib/hbwin/win_prn2.c * harbour/contrib/hbwin/win_prn3.c ! fixed to compile with WinCE Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/contrib/hbwin/win_prn3.c trunk/harbour/contrib/hbwin/win_tprn.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
Re: [Harbour] SF.net SVN: harbour-project:[13632] trunk/harbour
On Mon, 18 Jan 2010, Szak�ts Viktor wrote: > Is there any particular reason to define stubs > for non-WinCE winapi calls in hbwince.c, like > Ellipse(), Arc(), FrameRect(), FloodFill(), > FreeResource()? > Looks like these could be simply handled by > HB_OS_WIN_CE guards, just like we do for all > other similar case. 1. It's necessary to update code in many different places and in some cases it makes code really unreadable 2. I do not know which missing functions are real WinCE limitation and which one are missing only in provided WinCE RTL, i.e. each new release of MinGWCE adds new functions. It's much easier to update single file then scan whole code for different: #if ! defined( HB_OS_WIN_CE ) || ... Please note that in few cases these are very important functions, i.e. without file lock functions any WinCE application cannot access concurrently the same DBF files. 3. We added functions to emulate environment. We can also add functions to emulate some other things like current directory and in such case it's good to keep the same code for desktop windows and WinCE. BTW I also think that if some code can be compiled for WinCE and does not create some fixed dependencies which break existing functionality then we should compile it. I.e. with some minor fixes win_prn[123].c can be compiled for WinCE by MinGWCE. In current version of WinCE RTL low level functions do not exists but maybe they will be supported in the future or even by some 3-rd party extensions i.e. there is 3-rd party windows console for WinCE so it should be possible to use GTWIN with it so we can provide GTWIN for WinCE builds but of course it cannot be included in harbour.dll. Please also remember that new MinGW compilers support direct linking with .dll libraries and do not need any intermediate import libraries (BTW it's even suggested to eliminate import libraries from new projects because direct linking with .DLLs is faster and consumes less memory) so it's enough that user has valid .dlls to link his application and use new functionality. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13635] trunk/harbour
Revision: 13635 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13635&view=rev Author: vszakats Date: 2010-01-18 18:58:02 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 19:57 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * src/common/hbwince.c - Deleted definition of FreeResource(). It's noe used anywhere in Harbour, and its declaration was also missing. * contrib/hbqt/hbqt.h * contrib/hbqt/hbqt_destruct.cpp - Deleted no longer used macros: hbqt_ret_*(). + Added TOFIX to hbqt_par_*() where essentially the GC pointer type checking is completely worked around, which makes it easy to create GPFs by passing wrong pointer type to functions. Probably its unavoidable to introduce parameter validation to HBQT wrappers. Such validation could decide which types are accepted (f.e. objects and parent objects, whether NULL is accepted or rejected). If not accepted a proper RTE should be thrown instead of letting the app GPF. + Added two TOFIXes where low-level parameter retrieving function returns NULL. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/hbqt.h trunk/harbour/contrib/hbqt/hbqt_destruct.cpp trunk/harbour/src/common/hbwince.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
[Harbour] gtwin/non-unicode/HB_GTI_WINTITLE
Hi All, With gtwin, in non-UNICODE build, HB_GTI_WINTITLE encodes the strings wrongly, as it uses OSCODEPAGE, which is set to ANSI for proper encoding, while in this case it should use OEM codepage because that's what console API requires. Any idea what is the proper fix here? Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] I generate 64-bit EXE from my WinXP SP3 Harbor (SVN) + inGW (all 32bit)?
Hello, I generate 64-bit EXE from my WinXP SP3 Harbor (SVN) + inGW (all 32bit)? If yes, how? TIA BestRegards GVS ___ 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:[13634] trunk/harbour
Hi Pritpal, - Right-click GPF is gone. Thank you. This was again the case where a GPF had to be corrected on .prg level, so IMO we should explore the possibilities to avoid such .prg level error to cause a GPF in the first place. An RTE is a much friendlier behavior in this case. - The vertical/horizontal problem is still present. Brgds, Viktor On 2010 Jan 18, at 19:01, vouch...@users.sourceforge.net wrote: > Revision: 13634 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13634&view=rev > Author: vouchcac > Date: 2010-01-18 18:01:06 + (Mon, 18 Jan 2010) > > Log Message: > --- > 2010-01-18 09:55 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) > * contrib/hbide/hbide.prg > * contrib/hbide/ideactions.prg > * contrib/hbide/ideeditor.prg > * contrib/hbide/idemisc.prg > * contrib/hbide/ideobject.prg > * contrib/hbide/idesources.prg > * contrib/hbide/idethemes.prg >! Updated to honor latest changes. >+ Added: ZoomIn, ZoomOut feature, currently via toolbar. >! Fixed: open dialog respecting last opened path. >! Fixed: to display codec in the statusbar at the startup. >! Fixed: context menu gpf'ing if no prompt is selected. >+ Prepared: to allow extended book-"Mark" feature. >+ Prepared: to handle extended syntax highlighting. >! More artifacts I must be missing. > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbide/hbide.prg >trunk/harbour/contrib/hbide/ideactions.prg >trunk/harbour/contrib/hbide/ideeditor.prg >trunk/harbour/contrib/hbide/idemisc.prg >trunk/harbour/contrib/hbide/ideobject.prg >trunk/harbour/contrib/hbide/idesources.prg >trunk/harbour/contrib/hbide/idethemes.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
Re: [Harbour] SF.net SVN: harbour-project:[13633] trunk/harbour
>> Should be HB_TRUE and HB_FALSE, since they are >> passed to hb_retl() which is a Harbour API. >> >> >> >> >>> + object->setProperty( prop, ( int ) listBlock.size() ); >>> + >>> + return HB_TRUE; >>> } >>> + return HB_FALSE; >> >> Should be true and false, since the return value here >> is 'bool', plain C++ type. >> >> [ There may be other mis-uses, but I hope you get the general idea. ] >> > > Yes, I got it. Very subble difference. > I will update in a while. Thank you. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] errors with release 13584
> With an earlier version 13549 compiled 100% for BCC. With the latest > releases from Harbor began to appear that these errors. If I can fix it for > me to continue to use BCC ? > > > Franček Prijatelj wrote: >> >> I use mingw and MSVC8 with minigui extended (distribution by Grigory >> Filatov) >> and I have no problems with any compiler. >> Because minigui uses win32 appi, You have to #include >> > > What do I do / configure to generate the libraries for MiniGUI using MinGW / > MSVC The C compiler is irrelevant regarding this problem. Pls read my answers and ChangeLog entries. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] errors with release 13584
Hello Franček Prijatelj, With an earlier version 13549 compiled 100% for BCC. With the latest releases from Harbor began to appear that these errors. If I can fix it for me to continue to use BCC ? Franček Prijatelj wrote: > > I use mingw and MSVC8 with minigui extended (distribution by Grigory > Filatov) > and I have no problems with any compiler. > Because minigui uses win32 appi, You have to #include > What do I do / configure to generate the libraries for MiniGUI using MinGW / MSVC Best regards, Rossine. -- View this message in context: http://old.nabble.com/errors-with-release-13584-tp27170267p27214461.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:[13633] trunk/harbour
Hi
Viktor Szakáts wrote:
>
>> +HB_FUNC( HBQT_ISEMPTYQTPOINTER )
>> +{
>> + QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
>> +
>> + if( p && p->ph )
>> + hb_retl( false );
>> + else
>> + hb_retl( true );
>> +}
>
> Should be HB_TRUE and HB_FALSE, since they are
> passed to hb_retl() which is a Harbour API.
>
>
>
>
>> + object->setProperty( prop, ( int ) listBlock.size() );
>> +
>> + return HB_TRUE;
>>}
>> + return HB_FALSE;
>
> Should be true and false, since the return value here
> is 'bool', plain C++ type.
>
> [ There may be other mis-uses, but I hope you get the general idea. ]
>
Yes, I got it. Very subble difference.
I will update in a while.
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/Re%3A-SF.net-SVN%3A-harbour-project%3A-13633--trunk-harbour-tp27214392p27214456.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] SF.net SVN: harbour-project:[13634] trunk/harbour
Revision: 13634 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13634&view=rev Author: vouchcac Date: 2010-01-18 18:01:06 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 09:55 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbide/ideactions.prg * contrib/hbide/ideeditor.prg * contrib/hbide/idemisc.prg * contrib/hbide/ideobject.prg * contrib/hbide/idesources.prg * contrib/hbide/idethemes.prg ! Updated to honor latest changes. + Added: ZoomIn, ZoomOut feature, currently via toolbar. ! Fixed: open dialog respecting last opened path. ! Fixed: to display codec in the statusbar at the startup. ! Fixed: context menu gpf'ing if no prompt is selected. + Prepared: to allow extended book-"Mark" feature. + Prepared: to handle extended syntax highlighting. ! More artifacts I must be missing. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/ideactions.prg trunk/harbour/contrib/hbide/ideeditor.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideobject.prg trunk/harbour/contrib/hbide/idesources.prg trunk/harbour/contrib/hbide/idethemes.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] Re: SF.net SVN: harbour-project:[13633] trunk/harbour
Hi Pritpal,
On 2010 Jan 18, at 18:54, vouch...@users.sourceforge.net wrote:
> Revision: 13633
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13633&view=rev
> Author: vouchcac
> Date: 2010-01-18 17:54:15 + (Mon, 18 Jan 2010)
>
> Log Message:
> ---
> 2010-01-18 09:14 UTC-0800 Pritpal Bedi (prit...@vouchcac.com)
> Modified: trunk/harbour/contrib/hbqt/hbqt_base.cpp
> ===
> --- trunk/harbour/contrib/hbqt/hbqt_base.cpp 2010-01-18 16:03:09 UTC (rev
> 13632)
> +++ trunk/harbour/contrib/hbqt/hbqt_base.cpp 2010-01-18 17:54:15 UTC (rev
> 13633)
> @@ -78,6 +78,16 @@
>hb_retptr( object->findChild< QObject * >( hbqt_par_QString( 2 ) ) );
> }
>
> +HB_FUNC( HBQT_ISEMPTYQTPOINTER )
> +{
> + QGC_POINTER * p = ( QGC_POINTER * ) hb_parptrGC( hbqt_gcFuncs(), 1 );
> +
> + if( p && p->ph )
> + hb_retl( false );
> + else
> + hb_retl( true );
> +}
Should be HB_TRUE and HB_FALSE, since they are
passed to hb_retl() which is a Harbour API.
> Modified: trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp
> ===
> --- trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp 2010-01-18 16:03:09 UTC
> (rev 13632)
> +++ trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp 2010-01-18 17:54:15 UTC
> (rev 13633)
> +
> +bool HBEvents::hbConnect( PHB_ITEM pObj, int iEvent, PHB_ITEM bBlock )
> +{
> + HB_SYMBOL_UNUSED( pObj );
> + HB_SYMBOL_UNUSED( iEvent );
> + HB_SYMBOL_UNUSED( bBlock );
> +
> + QObject * object = ( QObject* ) hbqt_pPtrFromObj( 1 ); /* get
> sender*/
> +
> + if( object )
>{
> - HB_TRACE( HB_TR_DEBUG, ( "PTR_rel_HBEvents : Object not
> created with - new" ) );
> - p->ph = NULL;
> + PHB_ITEM codeblock = hb_itemNew( hb_param( 3, HB_IT_BLOCK |
> HB_IT_BYREF ) );
> + //PHB_ITEM codeblock = hb_itemNew( bBlock );
> +
> + char prop[ 20 ];
> + hb_snprintf( prop, sizeof( prop ), "%s%i%s", "P", iEvent, "P" ); /*
> Make it a unique identifier */
> +
> + listBlock << codeblock;
> + listObj << object;/* TOFIX: Reference to GC collected
> pointer is stored. */
> +
> + object->setProperty( prop, ( int ) listBlock.size() );
> +
> + return HB_TRUE;
>}
> + return HB_FALSE;
Should be true and false, since the return value here
is 'bool', plain C++ type.
[ There may be other mis-uses, but I hope you get the general idea. ]
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13633] trunk/harbour
Revision: 13633 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13633&view=rev Author: vouchcac Date: 2010-01-18 17:54:15 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 09:14 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbqt/hbqt.h * contrib/hbqt/hbqt_base.cpp * contrib/hbqt/hbqt_destruct.cpp * contrib/hbqt/hbqt_garbage.h * contrib/hbqt/hbqt_hbdbfmodel.cpp * contrib/hbqt/hbqt_hbevents.cpp * contrib/hbqt/hbqt_hbevents.h * contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp * contrib/hbqt/hbqt_hbqsyntaxhighlighter.h * contrib/hbqt/hbqt_hbqtableview.cpp * contrib/hbqt/hbqt_hbslots.cpp * contrib/hbqt/hbqt_hbslots.h * contrib/hbqt/qth/HBQTextBlockUserData.qth * contrib/hbqt/qth/QAbstractItemModel.qth * contrib/hbqt/qth/QSyntaxHighlighter.qth * contrib/hbqt/qth/QTableView.qth + contrib/hbqt/qth/HBQTableView.qth + contrib/hbqt/qth/HBDbfModel.qth + contrib/hbqt/qth/HBQSyntaxHighLighter.qth + Separated parts to auto/static generation. + contrib/hbqt/qth/HBEvents.qth + contrib/hbqt/qth/HBSlots.qth + Prepared to bring Events/Slots management on OO level. Stll not activated as I have some technical issues on c++ level. Just a matter of time... * contrib/hbqt/generator/hbqtgen.prg * contrib/hbqt/generator/qt45.qtp + This commit is generally towards separation of static/auto generated parts of classes which has been hanging in for manual updates to the structures indivisually if changes were made effective overhaul. * contrib/hbqt/qtcore/* * contrib/hbqt/qtgui/* * contrib/hbqt/qtnetwork/* Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbqt/generator/hbqtgen.prg trunk/harbour/contrib/hbqt/generator/qt45.qtp 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_garbage.h trunk/harbour/contrib/hbqt/hbqt_hbdbfmodel.cpp trunk/harbour/contrib/hbqt/hbqt_hbevents.cpp trunk/harbour/contrib/hbqt/hbqt_hbevents.h trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.cpp trunk/harbour/contrib/hbqt/hbqt_hbqsyntaxhighlighter.h trunk/harbour/contrib/hbqt/hbqt_hbqtableview.cpp trunk/harbour/contrib/hbqt/hbqt_hbslots.cpp trunk/harbour/contrib/hbqt/hbqt_hbslots.h trunk/harbour/contrib/hbqt/qtcore/QAbstractItemModel.cpp trunk/harbour/contrib/hbqt/qtcore/QAbstractListModel.cpp trunk/harbour/contrib/hbqt/qtcore/QAbstractTableModel.cpp trunk/harbour/contrib/hbqt/qtcore/QBitArray.cpp trunk/harbour/contrib/hbqt/qtcore/QByteArray.cpp trunk/harbour/contrib/hbqt/qtcore/QCoreApplication.cpp trunk/harbour/contrib/hbqt/qtcore/QDataStream.cpp trunk/harbour/contrib/hbqt/qtcore/QDate.cpp trunk/harbour/contrib/hbqt/qtcore/QDateTime.cpp trunk/harbour/contrib/hbqt/qtcore/QDir.cpp trunk/harbour/contrib/hbqt/qtcore/QEvent.cpp trunk/harbour/contrib/hbqt/qtcore/QEventLoop.cpp trunk/harbour/contrib/hbqt/qtcore/QFile.cpp trunk/harbour/contrib/hbqt/qtcore/QFileInfo.cpp trunk/harbour/contrib/hbqt/qtcore/QIODevice.cpp trunk/harbour/contrib/hbqt/qtcore/QLatin1Char.cpp trunk/harbour/contrib/hbqt/qtcore/QLatin1String.cpp trunk/harbour/contrib/hbqt/qtcore/QLine.cpp trunk/harbour/contrib/hbqt/qtcore/QLineF.cpp trunk/harbour/contrib/hbqt/qtcore/QList.cpp trunk/harbour/contrib/hbqt/qtcore/QLocale.cpp trunk/harbour/contrib/hbqt/qtcore/QMimeData.cpp trunk/harbour/contrib/hbqt/qtcore/QModelIndex.cpp trunk/harbour/contrib/hbqt/qtcore/QObject.cpp trunk/harbour/contrib/hbqt/qtcore/QPoint.cpp trunk/harbour/contrib/hbqt/qtcore/QPointF.cpp trunk/harbour/contrib/hbqt/qtcore/QProcess.cpp trunk/harbour/contrib/hbqt/qtcore/QRect.cpp trunk/harbour/contrib/hbqt/qtcore/QRectF.cpp trunk/harbour/contrib/hbqt/qtcore/QRegExp.cpp trunk/harbour/contrib/hbqt/qtcore/QResource.cpp trunk/harbour/contrib/hbqt/qtcore/QSettings.cpp trunk/harbour/contrib/hbqt/qtcore/QSignalMapper.cpp trunk/harbour/contrib/hbqt/qtcore/QSize.cpp trunk/harbour/contrib/hbqt/qtcore/QSizeF.cpp trunk/harbour/contrib/hbqt/qtcore/QStringList.cpp trunk/harbour/contrib/hbqt/qtcore/QTextBoundaryFinder.cpp trunk/harbour/contrib/hbqt/qtcore/QTextCodec.cpp trunk/harbour/contrib/hbqt/qtcore/QTextDecoder.cpp trunk/harbour/contrib/hbqt/qtcore/QTextEncoder.cpp trunk/harbour/contrib/hbqt/qtcore/QTextStream.cpp trunk/harbour/contrib/hbqt/qtcore/QThread.cpp trunk/harbour/contrib/hbqt/qtcore/QTime.cpp trunk/harbour/contrib/hbqt/qtcore/QTimer.cpp trunk/harbour/contrib/hbqt/qtcore/QTranslator.cpp trunk/harbour/contrib/hbqt/qtcore/QUiLoader.cpp trunk/harbour/contrib/hbqt/qtcore/QUrl.cpp trunk/harbour/contrib/hbqt/qtcore/QVariant.cpp trunk/harbour/contrib/hbqt/qtcore/TQAbstractItemModel.prg trunk/harbour/contrib
Re: [Harbour] errors with release 13584
> Thank You. > I see in hbdefs.h: > > /* Include windows.h if applicable and requested */ > #if defined( HB_OS_WIN_USED ) && defined( HB_OS_WIN ) > > #include > #if defined( __GNUC__ ) > #define HB_DONT_DEFINE_BASIC_TYPES > #endif > > But I'am compiling daily minigui extended with mingw and MSVC8. > Problem appeared lately. So my naive solution was to include windows.h > in *.c files. > Anyhow HbQt is responsible for it's Qt include files. > By my logic (I don't have Your deep knowledge of Harbour), any > toolkit should be responsible for it's environment. You're right in that. But, Harbour uses several C types which collide with Windows types, and until we fix this situation, this hack is - unfortunately - required. The historical reason is that these Windows types were also adopted by Clipper, so we started to use them in Harbour, too. For Clipper this wasn't such a huge problem, since it was MS-DOS based, but for Harbour it is, since it has to interface with virtually anything, among them: Windows. So, the proper fix is on the way, but it's a pretty tough and long process. My BOOL -> HB_BOOL, ULONG -> HB_SIZE fix was on such step. There is still several dozens of thousands of similar lines to fix, plus we will have to deal with compatibility, plus some tougher problems like existing HB_ULONG type. Thus it will still take some time to be able to make that right. To sum it up: The goal is to eliminate all Windows types from portable Harbour code, and make possible #include anywhere, without any interference with any Harbour code. This will also make it possible to build hbfimage on *nix platforms, and avoid any similar problem in the future. > I apreciate Your work very much Thank you. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] errors with release 13584
Hi Thank You. I see in hbdefs.h: /* Include windows.h if applicable and requested */ #if defined( HB_OS_WIN_USED ) && defined( HB_OS_WIN ) #include #if defined( __GNUC__ ) #define HB_DONT_DEFINE_BASIC_TYPES #endif But I'am compiling daily minigui extended with mingw and MSVC8. Problem appeared lately. So my naive solution was to include windows.h in *.c files. Anyhow HbQt is responsible for it's Qt include files. By my logic (I don't have Your deep knowledge of Harbour), any toolkit should be responsible for it's environment. Thank You I apreciate Your work very much BRGS Viktor Szakáts wrote: > >> I use mingw and MSVC8 with minigui extended (distribution by Grigory >> Filatov) >> and I have no problems with any compiler. >> Because minigui uses win32 appi, You have to #include > > You have to _request_ windows.h using HB_OS_WIN_USED > (formerly HB_OS_WIN32_USED). > > That's all. MINIGUI code wasn't updated during last > year to use the new one. > > 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/errors-with-release-13584-tp27170267p27214128.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:[13632] trunk/harbour
Thank you. Is there any particular reason to define stubs for non-WinCE winapi calls in hbwince.c, like Ellipse(), Arc(), FrameRect(), FloodFill(), FreeResource()? Looks like these could be simply handled by HB_OS_WIN_CE guards, just like we do for all other similar case. Brgds, Viktor On 2010 Jan 18, at 17:03, dru...@users.sourceforge.net wrote: > Revision: 13632 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13632&view=rev > Author: druzus > Date: 2010-01-18 16:03:09 + (Mon, 18 Jan 2010) > > Log Message: > --- > 2010-01-18 17:02 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/include/hbwince.h > * harbour/src/common/hbwince.c >- removed added for WinCE builds and not longer used wrappers > for some C RTL functions > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/include/hbwince.h >trunk/harbour/src/common/hbwince.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] errors with release 13584
> I use mingw and MSVC8 with minigui extended (distribution by Grigory > Filatov) > and I have no problems with any compiler. > Because minigui uses win32 appi, You have to #include You have to _request_ windows.h using HB_OS_WIN_USED (formerly HB_OS_WIN32_USED). That's all. MINIGUI code wasn't updated during last year to use the new one. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] errors with release 13584
> Hi > > You have to insert #include "windows.h" in every *.c file. (after #include > "hbapi.h") > I did it localy and it works. No, it's wrong solution. It's one of the most popular misconceptions about using windows API with Harbour. Instead, see these: 2010-01-13 15:10 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) 2009-02-04 01:09 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] errors with release 13584
Hi I use mingw and MSVC8 with minigui extended (distribution by Grigory Filatov) and I have no problems with any compiler. Because minigui uses win32 appi, You have to #include BRGS Rossine wrote: > > Hello Horodyski, > > I use minigui extended. Currently I use Borland BCC. What is the advantage > to using MingGW ? > > Best Regards, > > Rossine. > > -- View this message in context: http://old.nabble.com/errors-with-release-13584-tp27170267p27213560.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] errors with release 13584
Hi It's a consequence of . and commenting out #include "windows.h" Franček Prijatelj wrote: > > Hi > > You have to insert #include "windows.h" in every *.c file. (after #include > "hbapi.h") > I did it localy and it works. > It's a consequence of latest replacements of X types with HB_ in > Harbour trunk. > Anyhow I think that Grigory Filatov will have to change it. > > > BRGS > > > -- View this message in context: http://old.nabble.com/errors-with-release-13584-tp27170267p27213508.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] errors with release 13584
Hi You have to insert #include "windows.h" in every *.c file. (after #include "hbapi.h") I did it localy and it works. It's a consequence of latest replacements of X types with HB_ in Harbour trunk. Anyhow I think that Grigory Filatov will have to change it. BRGS Rossine wrote: > > Hello, > > I compile minigui com this release and i see this errors: > > [ERRORS] > > MiniGui.lib > > Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland > h_scrsaver.c: > h_edit.c: > h_edit_ex.c: > h_error.c: > h_ipaddress.c: > c_ipaddress.c: > Error E2257 c:\bcc55\include\prsht.h 90: , expected > Error E2293 c:\bcc55\include\prsht.h 97: ) expected > Error E2293 c:\bcc55\include\prsht.h 98: ) expected > Error E2139 c:\bcc55\include\prsht.h 137: Declaration missing ; > Error E2238 c:\bcc55\include\prsht.h 138: Multiple declaration for 'DWORD' > Error E2344 c:\bcc55\include\prsht.h 137: Earlier declaration of 'DWORD' > Error E2139 c:\bcc55\include\prsht.h 138: Declaration missing ; > Error E2139 c:\bcc55\include\prsht.h 139: Declaration missing ; > Error E2139 c:\bcc; > > ... and more > > [ENDERRORS] > > How to fix this ? > > Best Regards, > > Rossine. > > -- View this message in context: http://old.nabble.com/errors-with-release-13584-tp27170267p27213432.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] SF.net SVN: harbour-project:[13632] trunk/harbour
Revision: 13632 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13632&view=rev Author: druzus Date: 2010-01-18 16:03:09 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 17:02 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbwince.h * harbour/src/common/hbwince.c - removed added for WinCE builds and not longer used wrappers for some C RTL functions Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbwince.h trunk/harbour/src/common/hbwince.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
Re: [Harbour] SF.net SVN: harbour-project:[13629] trunk/harbour
On Mon, 18 Jan 2010, Szak�ts Viktor wrote: Hi, > Shouldn't we just delete them? > We can retrieve them from old SVN revisions anytime. Yes, we should. I'll remove them in next commit. best regards, Przemek ___ 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:[13629] trunk/harbour
Shouldn't we just delete them? We can retrieve them from old SVN revisions anytime. Brgds, Viktor On 2010 Jan 18, at 15:41, dru...@users.sourceforge.net wrote: > Revision: 13629 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13629&view=rev > Author: druzus > Date: 2010-01-18 14:41:12 + (Mon, 18 Jan 2010) > > Log Message: > --- > 2010-01-18 15:40 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/include/hbwince.h > * harbour/src/common/hbwince.c >- disabled not longer necessary in WinCE builds system() and strerror() > functions > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/include/hbwince.h >trunk/harbour/src/common/hbwince.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13631] trunk/harbour
Revision: 13631 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13631&view=rev Author: vszakats Date: 2010-01-18 15:36:56 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 16:34 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * include/hbcompdf.h * src/compiler/cmdcheck.c * src/compiler/hbmain.c * src/compiler/hbcomp.c * src/compiler/hbopt.c * src/compiler/hbusage.c * src/compiler/hbgenerr.c + Added options to control error/warning output format/style in Harbour, to make it possible to switch to formats which are handled by popular IDEs, like Eclipse, Code::Blocks. Currently these are supported: -ge[0]: Clipper compatible (default) -ge1: "IDE friendly". Mimics the one submitted by Lorenzo for Eclipse. The goal is to cover the most IDEs with the less options, so please test them to reach this optimum. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbcompdf.h trunk/harbour/src/compiler/cmdcheck.c trunk/harbour/src/compiler/hbcomp.c trunk/harbour/src/compiler/hbgenerr.c trunk/harbour/src/compiler/hbmain.c trunk/harbour/src/compiler/hbopt.c trunk/harbour/src/compiler/hbusage.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
[Harbour] Printing OEM_CHARSET win_prn()
Hi!
Still can not print graphics for example, chr(178).
#include 'hbwin.ch'
REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PTISO
Procedure Main ()
aPrn := GetPrinters()
HB_CDPSelect( "PTISO" )
HB_LANGSELECT( 'PT' )
If empty(aPrn)
MsgStop("Error")
return .f.
EndIf
oPrn := win_prn():New(GetDefaultPrinter())
oPrn :LandScape := .f.
oPrn :Copies:= 1
if !oPrn:Create()
MsgStop("error")
return nil
endif
if !oPrn:StartDoc("test")
MsgStop("Error")
return nil
EndIf
//oPrn:CharSet(ANSI_CHARSET)
//oPrn:Setfont('Lucida Console',,11) // oPrn:Setfont('Terminal',,12)
oPrn:CharSet(OEM_CHARSET)
oPrn:Setfont('Lucida Console',,11)
oPrn:SetPrc(1,0) //Is necessary, because if I omit not print first line.
oPrn:TextOut('Charset is: '+str(oPrn:Charset(),5),.t.)
oPrn:TextOut('Font Is: '+oPrn:FontName,.t.)
For n := 1 to 255
oPrn:TextOut(chr(n),.t.)
if n == 60 .or. n == 120 .or. n == 180 .or. n == 240
oPrn:NewPage()
EndIf
Next
oPrn:EndDoc()
Best regards,
Itamar M. Lins Jr.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] errors with release 13584
Hello All, Thanks for the tips and explanations but for now I want to continue using the borland. Today I tried to compile with the 13627 release and the errors continue. Using the 13549 release everything works OK. Below I list some of the errors: [ERRORS] MiniGui.lib Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland h_scrsaver.c: h_edit.c: h_edit_ex.c: h_error.c: h_ipaddress.c: c_ipaddress.c: Error E2257 c:\bcc55\include\prsht.h 90: , expected Error E2293 c:\bcc55\include\prsht.h 97: ) expected Error E2293 c:\bcc55\include\prsht.h 98: ) expected Error E2139 c:\bcc55\include\prsht.h 137: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 138: Multiple declaration for 'DWORD' Error E2344 c:\bcc55\include\prsht.h 137: Earlier declaration of 'DWORD' Error E2139 c:\bcc55\include\prsht.h 138: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 139: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 141: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 143: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 149: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 150: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 151: Multiple declaration for 'LPCSTR' Error E2344 c:\bcc55\include\prsht.h 143: Earlier declaration of 'LPCSTR' Error E2238 c:\bcc55\include\prsht.h 152: Multiple declaration for 'LPCSTR' Error E2344 c:\bcc55\include\prsht.h 143: Earlier declaration of 'LPCSTR' Error E2139 c:\bcc55\include\prsht.h 152: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 153: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 154: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 155: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 156: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 159: Multiple declaration for 'LPCSTR' Error E2344 c:\bcc55\include\prsht.h 143: Earlier declaration of 'LPCSTR' Error E2139 c:\bcc55\include\prsht.h 159: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 160: Multiple declaration for 'LPCSTR' Error E2228 c:\bcc55\include\prsht.h 160: Too many error or warning messages *** 26 errors in Compile *** h_monthcal.c: c_monthcal.c: Error E2257 c:\bcc55\include\prsht.h 90: , expected Error E2293 c:\bcc55\include\prsht.h 97: ) expected Error E2293 c:\bcc55\include\prsht.h 98: ) expected Error E2139 c:\bcc55\include\prsht.h 137: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 138: Multiple declaration for 'DWORD' Error E2344 c:\bcc55\include\prsht.h 137: Earlier declaration of 'DWORD' Error E2139 c:\bcc55\include\prsht.h 138: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 139: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 141: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 143: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 149: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 150: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 151: Multiple declaration for 'LPCSTR' Error E2344 c:\bcc55\include\prsht.h 143: Earlier declaration of 'LPCSTR' Error E2238 c:\bcc55\include\prsht.h 152: Multiple declaration for 'LPCSTR' Error E2344 c:\bcc55\include\prsht.h 143: Earlier declaration of 'LPCSTR' Error E2139 c:\bcc55\include\prsht.h 152: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 153: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 154: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 155: Declaration missing ; Error E2139 c:\bcc55\include\prsht.h 156: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 159: Multiple declaration for 'LPCSTR' Error E2344 c:\bcc55\include\prsht.h 143: Earlier declaration of 'LPCSTR' Error E2139 c:\bcc55\include\prsht.h 159: Declaration missing ; Error E2238 c:\bcc55\include\prsht.h 160: Multiple declaration for 'LPCSTR' Error E2228 c:\bcc55\include\prsht.h 160: Too many error or warning messages *** 26 errors in Compile *** h_help.c: ... [ENDERRORS] You can correct these mistakes and others for i use this last release ? Best Regards, Rossine. -- View this message in context: http://old.nabble.com/errors-with-release-13584-tp27170267p27211627.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] Re: run/hb_run/win_rundetached/wapi_shellexecute
wapi won't work for sure in linux In linux, to have a really detached process I usually do a: at -f "/path/to/a/shell/script" now In this way I'm sure stdout,stderr,stdin are "free" at returns immediately and the daemon atq runs the detached job. Another way is to use: nohup /path/to/a/shell/script & > /dev/null 2>&1 I never run it from Harbour... but for example from php or other applications. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13630] trunk/harbour
Revision: 13630 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13630&view=rev Author: druzus Date: 2010-01-18 14:54:31 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 15:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/common/hbwince.c - removed LocalLock()/LocalUnlock()/LocalHandle() function wrappers for WinCE builds - we do not use these functions in current code * harbour/contrib/xhb/xhw32prn.prg - removed commented :AskProperties - it's already implemented in WIN_PRN class Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/xhw32prn.prg trunk/harbour/src/common/hbwince.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
[Harbour] SET PRINTER TO
Hi All, Above extension works in xhb but is not supported in Harbour. Actually for good reason, so my intent is not to propose it for inclusion, but I still wonder what is the easiest way (least code change) to achieve the same result in Harbour. [ NOTICE: This feature can only work if printer controls codes match those supported by the printer, and it's easily possible the printer doesn't support raw input _at all_. Plus it makes SET PRINTER TO incompatible. ] --- SET PRINTER TO ( win_PrinterGetDefault() ) ... SET PRINTER TO --- is equivalent to something like this in Harbour: --- [untested] LOCAL cTempName FClose( hb_FTempCreateEx( @cTempName ) ) SET PRINTER TO ( cTempName ) ... SET PRINTER TO win_PrintFileRaw( win_PrinterGetDefault(), cTempName ) FErase( cTempName ) --- Anyhow, this is my suggestion to xhb users wanting to switch to Harbour. If you know a better way, pls speak up. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13629] trunk/harbour
Revision: 13629 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13629&view=rev Author: druzus Date: 2010-01-18 14:41:12 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 15:40 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbwince.h * harbour/src/common/hbwince.c - disabled not longer necessary in WinCE builds system() and strerror() functions Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/include/hbwince.h trunk/harbour/src/common/hbwince.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
Re: [Harbour] SF.net SVN: harbour-project:[13627] trunk/harbour
On Mon, 18 Jan 2010, Szak�ts Viktor wrote: > It works alright on both Win95 and Win98. (also on Win7) Thank you. In my WINE version it returns IDOK even if I choose "CANCEL" so :create() method also returns .T. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: run/hb_run/win_rundetached/wapi_shellexecute
francesco perillo escribió: wapi_shellexecute(,,::pdfFileName ) DID WORK ! Hi francesco ! I have one more question to add to your interesting post... What is the linux equivalent to that ? I want to achieve exactly the same but on linux. TIA Angel ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13628] trunk/harbour
Revision: 13628 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13628&view=rev Author: vszakats Date: 2010-01-18 14:31:20 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 15:30 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/tests/testprn.prg + Brings up printer setup dialog if run with 'ask' cmdline parameter. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/tests/testprn.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
Re: [Harbour] SF.net SVN: harbour-project:[13627] trunk/harbour
It works alright on both Win95 and Win98. (also on Win7) Brgds, Viktor On 2010 Jan 18, at 14:57, dru...@users.sourceforge.net wrote: > Revision: 13627 > > http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13627&view=rev > Author: druzus > Date: 2010-01-18 13:57:04 + (Mon, 18 Jan 2010) > > Log Message: > --- > 2010-01-18 14:56 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > * harbour/include/hbapi.h > * harbour/src/common/hbver.c >+ added BOOL hb_iswin9x( void ) C function > > * harbour/src/rtl/version.c >+ added HB_OSISWIN9X() PRG function > > * harbour/src/rtl/gttone.c >% simplified the code using hb_iswin9x() function > >TODO: Check if WinCE support WinNT file IO functions and if yes then > replace in src/rtl/filesys.c 'if( hb_iswinnt() )' with > 'if( !hb_iswin9x() )' > > * harbour/contrib/hbwin/win_tprn.prg > * harbour/contrib/hbwin/win_prn1.c >+ added ::AskProperties in WIN_PRN class > If it is assigned .t. prior to calling ::Create(), a DocumentProperties > dialog is displayed. By Budyanto Dj. borrowed from xHarbour. > NOTE: this modification does not contain win9x hack present in >xHarbour. Please make tests and update this code if necessary > > Modified Paths: > -- >trunk/harbour/ChangeLog >trunk/harbour/contrib/hbwin/win_prn1.c >trunk/harbour/contrib/hbwin/win_tprn.prg >trunk/harbour/include/hbapi.h >trunk/harbour/src/common/hbver.c >trunk/harbour/src/rtl/gttone.c >trunk/harbour/src/rtl/version.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] WIN_DRAWBITMAP() with .png
Hi Maurilio, > I've never used tprn, but given a .png file you need to read it so that you > have a DIB or BITMAP in memory. > > I think that using freeimage you can achieve such a result. > > I hope this can, at least, point you in the right direction. Thanks for the suggestion, and this may indeed work, although for local reasons it's not an option for me, since I'd need to distribute a .dll with my app. (I never managed to build static libs of FreeImage, maybe even the license wouldn't permit it). Tried to find out how to make such conversion by looking at FreeImage code, but it's quite a complicated piece. libgd has nice png read routine, but it misses the save part AFAICS. I read that some printer drivers are accepting png and jpeg directly, so it may work. As a next step I'll try that. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13627] trunk/harbour
Revision: 13627 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13627&view=rev Author: druzus Date: 2010-01-18 13:57:04 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 14:56 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbapi.h * harbour/src/common/hbver.c + added BOOL hb_iswin9x( void ) C function * harbour/src/rtl/version.c + added HB_OSISWIN9X() PRG function * harbour/src/rtl/gttone.c % simplified the code using hb_iswin9x() function TODO: Check if WinCE support WinNT file IO functions and if yes then replace in src/rtl/filesys.c 'if( hb_iswinnt() )' with 'if( !hb_iswin9x() )' * harbour/contrib/hbwin/win_tprn.prg * harbour/contrib/hbwin/win_prn1.c + added ::AskProperties in WIN_PRN class If it is assigned .t. prior to calling ::Create(), a DocumentProperties dialog is displayed. By Budyanto Dj. borrowed from xHarbour. NOTE: this modification does not contain win9x hack present in xHarbour. Please make tests and update this code if necessary Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_tprn.prg trunk/harbour/include/hbapi.h trunk/harbour/src/common/hbver.c trunk/harbour/src/rtl/gttone.c trunk/harbour/src/rtl/version.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
[Harbour] SF.net SVN: harbour-project:[13626] trunk/harbour
Revision: 13626 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13626&view=rev Author: vszakats Date: 2010-01-18 13:37:42 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 14:36 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * hbwin/hbwapi.h * hbwin/win_prn1.c + Added HFONT GC interface. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwapi.h trunk/harbour/contrib/hbwin/win_prn1.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
Re: [Harbour] SF.net SVN: harbour-project:[13625] trunk/harbour
On Mon, 18 Jan 2010, vszak...@users.sourceforge.net wrote: > 2010-01-18 13:27 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) > * contrib/hbwin/win_prn1.c > * contrib/hbwin/hbwapi.h > * Renamed static GC related functions. > ! WIN_SETPEN() fixed to retrieve pointer from _2nd_ param. > (it was 1st previously, pls review me) > ! WIN_SETPEN() fixed to not allocate new GC pointer if > an existing GC pointer was passed as 2nd parameter. > (please review me) It's OK, thank you very much for fixing me. I should be more careful. best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: off topic - letodb
> Now I found 2 problem with letodb. > error LNK2019: unresolved external symbol _hb_cdpnTranslate referenced in It's an obsolete function since 1.0.1, it must be fixed like I did recently on SVN. Pls see those entries and diffs for details. > function _letoKeyToStr > error LNK2019: unresolved external symbol _GetComputerNameA referenced in > function _leto_NetName It's copied code from Harbour SVN, and thus it's best to update it according to current Harbour SVN. Or, at least to update it not to use forced ANSI Windows API. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13625] trunk/harbour
Revision: 13625 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13625&view=rev Author: vszakats Date: 2010-01-18 12:30:26 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 13:27 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_prn1.c * contrib/hbwin/hbwapi.h + Added public functions to return and retrieve HDC and HPEN handles. This makes it possible to use these in 3rd party code and other parts of hbwin lib. F.e. to create pure wrappers for GDI functions. + win_prn1.c now uses hbwapi_ret_*() functions to return HDC and HPEN handles. * Renamed static GC related functions. ! WIN_SETPEN() fixed to retrieve pointer from _2nd_ param. (it was 1st previously, pls review me) ! WIN_SETPEN() fixed to not allocate new GC pointer if an existing GC pointer was passed as 2nd parameter. (please review me) * contrib/hbwin/mapi.c * contrib/hbwin/wapi_commctrl.c ! Fixed to compile with Cygwin. [TOMERGE 2.0] * contrib/hbwin/win_prn1.c - Deleted unnecessary winspool.h header. * contrib/hbwin/win_prn2.c * contrib/hbwin/win_prn3.c - Deleted winspool.h header for LCC compiler. We don't support LCC compiler in Harbour. ! Cleaned windows.h inclusion. * contrib/hbfimage/fi_winfu.c * contrib/hbfimage/fi_wrp.c * Formatting. + TOFIX added to use GC collected pointers. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbfimage/fi_winfu.c trunk/harbour/contrib/hbfimage/fi_wrp.c trunk/harbour/contrib/hbwin/hbwapi.h trunk/harbour/contrib/hbwin/mapi.c trunk/harbour/contrib/hbwin/wapi_commctrl.c trunk/harbour/contrib/hbwin/win_prn1.c trunk/harbour/contrib/hbwin/win_prn2.c trunk/harbour/contrib/hbwin/win_prn3.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
[Harbour] Re: off topic - letodb
Now I found 2 problem with letodb.
error LNK2019: unresolved external symbol _hb_cdpnTranslate referenced in
function _letoKeyToStr
error LNK2019: unresolved external symbol _GetComputerNameA referenced in
function _leto_NetName
2009-09-11 20:37 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/include/hbapi.h
+ added hb_xgrabz() and hb_xmemdup() macros
* harbour/include/hbapicdp.h
* harbour/source/rtl/cdpapi.c
+ added new functions which can be used in translations changing the
size of trnaslated strings:
hb_cdpDup(), hb_cdpnDup(), hb_cdpnDup2(), hb_cdpnDup3(),
hb_cdpnDupLen(), hb_cdpnDup2Len()
Now hb_cdp[n]Translate() functions are depreciated.
+ added pseduto codepage "UTF8" which can be used in trnaslations only
+ added new function hb_cdpFindExt() which allows to chose pseudo CPs
1)In leto1.c piece of codigo
--->8---
static USHORT letoKeyToStr( LETOAREAP pArea, char * szKey, char cType,
PHB_ITEM pKey )
{
USHORT uiKeyLen;
if( cType == 'N' )
{
char * sNum = hb_itemStr( pKey, NULL, NULL );
uiKeyLen = strlen(sNum);
memcpy( szKey, sNum, uiKeyLen );
hb_xfree( sNum );
}
else if( cType == 'D' )
{
hb_itemGetDS( pKey, szKey );
uiKeyLen = 8;
}
else if( cType == 'L' )
{
szKey[0] = (hb_itemGetL(pKey))? 'T':'F';
uiKeyLen = 1;
}
else
{
uiKeyLen = hb_itemGetCLen(pKey);
memcpy( szKey, hb_itemGetCPtr(pKey), uiKeyLen );
hb_cdpnTranslate( szKey, hb_cdp_page, pArea->area.cdPage, uiKeyLen );
}
szKey[uiKeyLen] = '\0';
return uiKeyLen;
}
-8<
2) In net.c
>8--
#elif defined(HB_OS_WIN_32) || defined( HB_OS_WIN )
DWORD ulLen = 32;
char szValue[32], *szRet;
szValue[ 0 ] = '\0';
GetComputerNameA( szValue, &ulLen );
ulLen = strlen( szValue );
szRet = (char*) hb_xgrab( ulLen+1 );
memcpy( szRet, szValue, ulLen );
szRet[ulLen] = '\0';
return szRet;
#else
---8<
Someone can fix this ?
Best regards,
Itamar M. Lins Jr.
___
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:[13596] trunk/harbour
On Mon, 18 Jan 2010, Szak�ts Viktor wrote: > > I can implement it but the tests will cause problem for me due to > > limited access to MS-Windows machines. > > Can I ask other users to make them? > I can make tests on Win9x. Thank you, I'll commit modifications ASAP. best regards, Przemek ___ 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:[13596] trunk/harbour
>>> Win9x systems at all. This way at least users are >>> free of surprises. ] >> According to this: >> http://msdn.microsoft.com/en-us/library/dd183576(VS.85).aspx >> "If the function does not display the property sheet and is successful, the >> return value is IDOK." >> This is not terribly helpful information, but it's possible that's >> what happens on Win95. >> Here's an article which suggest that this feature should >> work on Win95 as well: >> http://support.microsoft.com/kb/118622 >> Maybe we should implement it in hbwin and try on Win9x. > > Thank you very much for information. > Please note that ion example code in the above article the value > returned by 3-rd call to DocumentProperties() is ignored. > I can implement it but the tests will cause problem for me due to > limited access to MS-Windows machines. > Can I ask other users to make them? I can make tests on Win9x. Brgds, Viktor ___ 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:[13596] trunk/harbour
On Mon, 18 Jan 2010, Szak�ts Viktor wrote: Hi, > >> :AskProperties > >> which allow to activate DocumentProperties dialog from :Create() method > >> so user can make interactively his own settings. Below is xHarbour > >> ChangeLog entry which introduced this feature. > >> Question to windows users: > >> Do you think it's valuable extension? Should we add it too? > > Hm, can't see much against it, if it works properly. > > [ Update: After reading the ChangeLog entry, the Win95 > > weirdness makes this feature rather strange. I'd guess > > that this omission have a proper solution, and always > > assuming that user clicked 'OK' (IOW ignoring what > > user selected) is not the right thing to do. IMO this > > needs to fixed to be true to Harbour quality. It's > > also better solution to not present the windows on > > Win9x systems at all. This way at least users are > > free of surprises. ] > According to this: >http://msdn.microsoft.com/en-us/library/dd183576(VS.85).aspx > "If the function does not display the property sheet and is successful, the > return value is IDOK." > This is not terribly helpful information, but it's possible that's > what happens on Win95. > Here's an article which suggest that this feature should > work on Win95 as well: >http://support.microsoft.com/kb/118622 > Maybe we should implement it in hbwin and try on Win9x. Thank you very much for information. Please note that ion example code in the above article the value returned by 3-rd call to DocumentProperties() is ignored. I can implement it but the tests will cause problem for me due to limited access to MS-Windows machines. Can I ask other users to make them? best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE
Hi! > It is strange. Qt documentation does not tell about Ctrl+W > behavior with QPlainTextEdit() and I have not implemented it. > Anybody has some clue. This is a shortcut from the File menu. Remember the idea of letting these and other settings in a custom file? Regards, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] HBIDE
Hi Rodrigo Machado wrote: > > At open a file, in the OpenDialog set the default path equal the opened > file. > Fixed to respect last opened path. First time it will be hb_dirBase() + "projects". Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE-tp27132880p27209226.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
Hi Rodrigo Machado wrote: > > - At press ESC is closed the file, equals CTRL+W. > See this ScreenCast. http://www.teleguia.com.py/hbide/esc_bug.ogv > It is strange. Qt documentation does not tell about Ctrl+W behavior with QPlainTextEdit() and I have not implemented it. Anybody has some clue. > - At startup, the enconding no show in status bar, but working properly. > Fixed. Thank you. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/HBIDE-tp27132880p27209213.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] C++ - How to pass self as an argument to a function from C++ class
Hello Przemysław Czerpak wrote: > >> What is the syntax to pass self as pointer to a function >> from withing C++ class. > > 'this' > Damm. It goesin front of eyes in numerous examples, and I... Thank you. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/C%2B%2B---How-to-pass-self-as-an-argument-to-a-function-from-C%2B%2B-class-tp27208412p27209147.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] WIN_DRAWBITMAP() with .png
Viktor, I've never used tprn, but given a .png file you need to read it so that you have a DIB or BITMAP in memory. I think that using freeimage you can achieve such a result. I hope this can, at least, point you in the right direction. Maurilio. Viktor Szakáts wrote: > Hi All, > > Can someone tell, how to convert a .png to > something which can be passed as WIN_DRAWBITMAP() > parameter? > > Brgds, > Viktor > > ___ > Harbour mailing list (attachment size limit: 40KB) > Harbour@harbour-project.org > http://lists.harbour-project.org/mailman/listinfo/harbour > -- __ | | | |__| Maurilio Longo |_|_|_|| farmaconsult s.r.l. ___ 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:[13596] trunk/harbour
Hi Przemek, >> :AskProperties >> which allow to activate DocumentProperties dialog from :Create() method >> so user can make interactively his own settings. Below is xHarbour >> ChangeLog entry which introduced this feature. >> Question to windows users: >> Do you think it's valuable extension? Should we add it too? > > Hm, can't see much against it, if it works properly. > > [ Update: After reading the ChangeLog entry, the Win95 > weirdness makes this feature rather strange. I'd guess > that this omission have a proper solution, and always > assuming that user clicked 'OK' (IOW ignoring what > user selected) is not the right thing to do. IMO this > needs to fixed to be true to Harbour quality. It's > also better solution to not present the windows on > Win9x systems at all. This way at least users are > free of surprises. ] According to this: http://msdn.microsoft.com/en-us/library/dd183576(VS.85).aspx "If the function does not display the property sheet and is successful, the return value is IDOK." This is not terribly helpful information, but it's possible that's what happens on Win95. Here's an article which suggest that this feature should work on Win95 as well: http://support.microsoft.com/kb/118622 Maybe we should implement it in hbwin and try on Win9x. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE: [Harbour] How harbour create Multi Tier application?
>-Original Message- >From: Massimo Belgrano [mailto:mbelgr...@deltain.it] >Sent: Saturday, January 16, 2010 3:18 PM >To: Harbour Project Main Developer List. >Subject: [Harbour] How harbour create Multi Tier application? > ... >What is rpc protocol? RemoteProcedureCall : http://it.wikipedia.org/wiki/Chiamata_di_procedura_remota :) Regards, Marek Horodyski ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13624] trunk/harbour
Revision: 13624 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13624&view=rev Author: vszakats Date: 2010-01-18 10:40:16 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 11:39 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/hbwin.ch * contrib/hbwin/win_tprn.prg + Added constants for WIN_SETBKMODE() mode parameter. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/hbwin.ch trunk/harbour/contrib/hbwin/win_tprn.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
Re: [Harbour] Re: OT: file size
Hi David,
>> I did notice it and thanks for these tests, but I'd suggest
>> to patch (or send patches for) existing .hbc files, after you
>> tested them with hbmk2 successfully using OS/2 specific 3rd
>> party lib names. It's rather inefficient if I edit them without
>> testing and we iterate it endlessly. Plus for me it's impossible
>> to decide which one of the possible true OS/2 lib name setups
>> should be put into SVN .hbc files. Ideally the default here
>> should be what _most_ OS/2 users would expect.
>
>> You should add:
>> {os2}libs=...
>
>> Plus you should exclude existing libs= lines with
>> {!os2} if they are not currently protected.
>
> Messages were for specific cases, not only libs list
>
> a) hbcurl
> * Fail to build with OpenWatcom
> * undefined symbols in os2gcc
> Alternatives:
> - Fix source code
> - or, perhaps hbcurl does not work in OpenWatcom
Easily possible. The errors you sent are
all reported in system headers and libcurl
headers. We can't fix those in Harbour.
Ideally this problem should be reported to
libcurl developers.
Unfortunately there is no way to disable
dependency detection for platform/compiler
combinations (os2/watcom) in Harbour, so OS/2
users will have to make sure not to set
HB_WITH_CURL when building for watcom.
> b) hbcairo
> Missing function in one sample
> Alternatives:
> - Fix source code
> - or, perhaps sample fail in any platform
It seems that OS/2 cairo version has no
'CAIRO_HAS_IMAGE_SURFACE' support, and this
makes test app break. The correct fix here is to
provide Harbour level function regardless of
cairo version, but return permanent error in
this case. This is the method used in all other
Harbour lib bindings.
I hope Mindaugas can fix it.
> c) Contrib libs readme*
> Libs list required for each contrib based on my tests
> Alternatives:
> - Modify *.h* files by myself
> - Describe list, done in readme* file
Lib dependencies are never documented in INSTALL,
instead, they are configured in appropriate .hbc files.
In INSTALL, we can document _package_ dependencies
and packages web links, but never actual lib filenames.
> d) hbqt
> List of source files which have errors on OS/2 and detailed flow of tests
> Alternatives:
> - Fix source code
> - Perhaps this code does not work on OS/2 - Qt
I can't comment on those. Only that the bool conversion
problem could probably be easily fixed (unless it's an
OS/2 compiler bug), for someone good in C++.
>
> But Pritpal is highly focused in hbide now :-)
>
> Most errors are of kind:
> 'A' is not a member of 'B'
> class 'C' has no member named 'D'
> 'E' was not declared in this scope
> expected primary-expression before ')' token
> invalid use of incomplete type 'F'
> incomplete type 'G' used in nested name specifier
> forward declaration of 'H'
> expected type-specifier before 'I'
>
> I do not know if:
> - Are valid errors which must be fixed on Harbour
> - Other compiler switchs required
> - They are errors related to OS/2-Qt code and not Harbour
>
>>> My mail file for Harbour messages reached 105 Mb file size and no one
>>> editor in OS/2 can open it ( EPM, E, TEDIT, JEdit ) :-)
>
>> (if it's a text file you can use 'grep')
>
> But grep does not show context around each found
According to its own help, it does:
---
Context control:
-B, --before-context=NUM print NUM lines of leading context
-A, --after-context=NUM print NUM lines of trailing context
-C, --context=NUM print NUM lines of output context
-NUM same as --context=NUM
--color[=WHEN],
--colour[=WHEN] use markers to highlight the matching strings;
WHEN is `always', `never', or `auto'
---
Brgds,
Viktor
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] C++ - How to pass self as an argument to a function from C++ class
On Mon, 18 Jan 2010, Pritpal Bedi wrote: Hi, > What is the syntax to pass self as pointer to a function > from withing C++ class. 'this' best regards, Przemek ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13623] trunk/harbour
Revision: 13623 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13623&view=rev Author: druzus Date: 2010-01-18 10:21:26 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 11:20 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/dbinfo.ch * harbour/include/hbrdddbf.h * harbour/src/rdd/dbf1.c * harbour/src/rdd/dbfntx/dbfntx1.c * harbour/src/rdd/dbfnsx/dbfnsx1.c * renamed DB_DBFLOCK_XHB64 => DB_DBFLOCK_HB64 * harbour/contrib/hbwin/win_tprn.prg * updated some comments and formatting * harbour/contrib/xhb/Makefile + harbour/contrib/xhb/xhw32prn.prg + added WIN32PRN class, it inherits from WIN_PRN class hiding some differences between Harbour and xHarbour in paper size setting and separated horizontal and vertical alignment setting Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_tprn.prg trunk/harbour/contrib/xhb/Makefile trunk/harbour/include/dbinfo.ch trunk/harbour/include/hbrdddbf.h trunk/harbour/src/rdd/dbf1.c trunk/harbour/src/rdd/dbfnsx/dbfnsx1.c trunk/harbour/src/rdd/dbfntx/dbfntx1.c Added Paths: --- trunk/harbour/contrib/xhb/xhw32prn.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] C++ - How to pass self as an argument to a function from C++ class
Hi All
What is the syntax to pass self as pointer to a function
from withing C++ class.
void some_c_function( PHB_ITEM a, SomeType * some )
{
}
MyClass::MyClass()
{
return some_c_function( hb_param( 1, HB_IT_ANY ), ( MyClass * ) MyClass
);
}
Regards
Pritpal Bedi
--
View this message in context:
http://old.nabble.com/C%2B%2B---How-to-pass-self-as-an-argument-to-a-function-from-C%2B%2B-class-tp27208412p27208412.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] Re: OT: file size
Viktor, thanks:
For example, nobody have response for my recent messages about
hbcurl, hbcairo, hbqt because are considered as irrelevant in this
moment
I did notice it and thanks for these tests, but I'd suggest
to patch (or send patches for) existing .hbc files, after you
tested them with hbmk2 successfully using OS/2 specific 3rd
party lib names. It's rather inefficient if I edit them without
testing and we iterate it endlessly. Plus for me it's impossible
to decide which one of the possible true OS/2 lib name setups
should be put into SVN .hbc files. Ideally the default here
should be what _most_ OS/2 users would expect.
You should add:
{os2}libs=...
Plus you should exclude existing libs= lines with
{!os2} if they are not currently protected.
Messages were for specific cases, not only libs list
a) hbcurl
* Fail to build with OpenWatcom
* undefined symbols in os2gcc
Alternatives:
- Fix source code
- or, perhaps hbcurl does not work in OpenWatcom
b) hbcairo
Missing function in one sample
Alternatives:
- Fix source code
- or, perhaps sample fail in any platform
c) Contrib libs readme*
Libs list required for each contrib based on my tests
Alternatives:
- Modify *.h* files by myself
- Describe list, done in readme* file
d) hbqt
List of source files which have errors on OS/2 and detailed flow of tests
Alternatives:
- Fix source code
- Perhaps this code does not work on OS/2 - Qt
But Pritpal is highly focused in hbide now :-)
Most errors are of kind:
'A' is not a member of 'B'
class 'C' has no member named 'D'
'E' was not declared in this scope
expected primary-expression before ')' token
invalid use of incomplete type 'F'
incomplete type 'G' used in nested name specifier
forward declaration of 'H'
expected type-specifier before 'I'
I do not know if:
- Are valid errors which must be fixed on Harbour
- Other compiler switchs required
- They are errors related to OS/2-Qt code and not Harbour
My mail file for Harbour messages reached 105 Mb file size and no one
editor in OS/2 can open it ( EPM, E, TEDIT, JEdit ) :-)
(if it's a text file you can use 'grep')
But grep does not show context around each found
David Macias
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13622] trunk/harbour
Revision: 13622 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13622&view=rev Author: vszakats Date: 2010-01-18 10:04:53 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 11:04 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_tprn.prg ! Fix to prev. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbwin/win_tprn.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] SF.net SVN: harbour-project:[13621] trunk/harbour
Revision: 13621 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13621&view=rev Author: vszakats Date: 2010-01-18 10:00:41 + (Mon, 18 Jan 2010) Log Message: --- 2010-01-18 10:58 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbwin/win_tprn.prg ! Using constant. * Minor formatting/cleanup. * contrib/hbhpdf/harupdf.c ! HPDF_Page_GetMiterLimit() fixed to return double instead of long. As suggested by Saulius. [TOMERGE 2.0] * Formatting. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbhpdf/harupdf.c trunk/harbour/contrib/hbwin/win_tprn.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
Re: [Harbour] bug and patch for harupdf.ch, please review and apply
The same with HPDF_Page_GetMiterLimit Best regards, Saulius ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] run/hb_run/win_rundetached/wapi_shellexecute
I've integrated Harupdf in my program. Haru creates a file and I wanted to open the satndard, system defined pdf viewer. I opted to the simplest command: run( ::pdfFileName ) This worked flawlessy in my XP pro development notebook, opening the Acrobat Reader window while the Harbour program was still running. This morning I run the program on the Win 2k VM at the users site to do some integration testing and at the run() command I got a annoying message talking about redirecting win32 debug message to the remote collector.. annoying but still ok, harbour program still running... I then run the code on my XP pro office development workstation and Acrobat opened but Harbour program was LOCKED till I closed Acrobat I then started to investigate: run, __run, hb_run all do the same, block Harbour win_rundetached return false but probably I didn't really understand parameters... and probably I can't pass a pdf filename but should pass an executable filename wapi_shellexecute(,,::pdfFileName ) DID WORK ! Is it normal to have this different behaviour in run( ) command ? Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
