Revision: 10705
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10705&view=rev
Author: druzus
Date: 2009-03-27 01:46:36 + (Fri, 27 Mar 2009)
Log Message:
---
2009-03-27 02:53 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/tests/speedts
Imo is not valid to remove
gtwvg must remain because is part of harbourt history, also Przemyslaw
have made nice word about gtwvg and his sample
Probably in past day Viktor search cooperation and not informed about
your vacation think bad...
2009/3/26 Pritpal Bedi :
>
> I need groups viewpoi
Revision: 10704
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10704&view=rev
Author: vszakats
Date: 2009-03-27 00:55:52 + (Fri, 27 Mar 2009)
Log Message:
---
2009-03-27 01:52 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* utils/hbmk2/hbmk2.prg
*
procedure testolenew()
local oWord, oText
begin sequence
oWord = GetActiveObject( "Word.Application" )
recover
begin sequence
oWord = CreateObject( "Word.Application" )
recover
alert( "ERROR! Word not avialable." )
oWord = GetActiveObject( "Word.A
All,
As the end user, I just use a couple of contrib libs, so why we need
to worry about it? Why we just leave the contrib's away of the
official build? I think most of the harbour users are capable to build
them selves any contrib by just using the make files provided by the
author... For those t
Hi Pritpal,
No, it's not scheduled for removal, but I'm in permanent and serious trouble
because of GTWVG code and it essentially makes every build testing
take much longer as it would normally take due to
the tons of problems it generates, I haven't enough
resources to clean it up myself, and I d
Pritpal Bedi wrote:
>
> Hi
>
>
> Vagelis Skarmaliorakis wrote:
>>
>> My os is archlinux 64bit., desktop is KDE 4.2.1
>>
>> Finally i got hbqt lib after some changes:
>>
>> commented the line //#if QT_VERSION >= 0x040500 and //#endif at files
>>
>
> I guess that you are not having QT 4.
Revision: 10703
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10703&view=rev
Author: vszakats
Date: 2009-03-26 21:02:42 + (Thu, 26 Mar 2009)
Log Message:
---
2009-03-26 22:01 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* contrib/hbodbc/tests/odbc
Hi
Vagelis Skarmaliorakis wrote:
>
> My os is archlinux 64bit., desktop is KDE 4.2.1
>
> Finally i got hbqt lib after some changes:
>
> commented the line //#if QT_VERSION >= 0x040500 and //#endif at files
>
I guess that you are not having QT 4.5 installed on your machine.
This code is ta
Hello Everybody
Back from a vacation...
I read all messages piled so large and have
come-up one significant note that GTWVG has been
scheduled to be REMOVED from Harbour repository
after 4 years of its presence here and about 7 years
presence on xHarbour.
The reasons put forth can be present
Hi,
My os is archlinux 64bit., desktop is KDE 4.2.1
Finally i got hbqt lib after some changes:
commented the line //#if QT_VERSION >= 0x040500 and //#endif at files
hbqt_qabstractbutton.cpp
hbqt_qabstractitemview.cpp
Also at hbqt_qabstractitemview.cpp i changed the include line to
Usin
On Wed, 25 Mar 2009, Mindaugas Kavaliauskas wrote:
Hi,
> one of missing features is parameters passed by reference. Iterators is not
> implemented also, but I do not know if it is implemented in current win_ole
> code.
Current code is very short and simple. At least I understand it so far ;-)
Revision: 10702
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10702&view=rev
Author: druzus
Date: 2009-03-26 19:47:39 + (Thu, 26 Mar 2009)
Log Message:
---
2009-03-26 20:54 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbole
>
> But so far I haven't seen that any of Windows developers here
> tried to document dependencies created by different Windows C
> compilers. I only heard few times that binaries created by compiler
> XYZ do not work with some older version ZXY Windows version but
> without any precise information
Hi Toninho,
Il 26/03/2009 17.12, toni...@fwi ha scritto:
Hi Francesco.
do you use MSVC ? If yes, do you have tested same code after removing
-TP flag in config/msvc.cf and rebuild entire SVN ?
No, I´m using BCC 6.10. New OLE seems work fine, except that
GetActiveObject() is not working, as
On Thu, 26 Mar 2009, Massimo Belgrano wrote:
Hi,
> gtxwc have one platform supported (linux)
> (so imo is related to this topics)
> If the rule for exist is related to number of platform supported
> gtwvg and gtxwc must be is same (irregolar) situation
GTXWC is supported by Linux, HPUX, SunOS, B
>New implementation does not generate RT error but simply returns NIL.
>It's not longer necessary to use BEGIN SEQUENCE / END (BTW WITH {|e|break}
>is missing) or TRY/CATCH.
Thank you Przemek.
Best regards,
Toninho.
___
Yahoo! Mail - Sempre
Gtwvg is a highly win specific lib with no counterparts on other
platforms. Your prg code will be win only. Plus it's x86 specific, was
never successfully tested on ce, x64, unicode, uses internals, non
ansi c code, breaks core and other contrib namespaces, has redundant
winapi parts, code non port
Ok, but can you explain where gtwvg not follow this route
I have read only about platform problem in precedent post
2009/3/26 Viktor Szakáts :
> Gtxwc is the pair of gtwvt. Both plat spec, both core & compatible
> with each other. I'm not "fire" at anyone in any personal sense, but a
> release is
Gtxwc is the pair of gtwvt. Both plat spec, both core & compatible
with each other. I'm not "fire" at anyone in any personal sense, but a
release is unlikely with current approach.
On 3/26/09, Massimo Belgrano wrote:
> 2009/3/26 Viktor Szakáts :
>>> In my opinion gtwvt will be very useful for har
On Thu, 26 Mar 2009, toni...@fwi wrote:
Hi,
> But with a more extensive test here I found that this code doesn´t
> work:
> procedure testolenew()
>local oWord, oText
>begin sequence
> oWord = GetActiveObject( "Word.Application" )
>recover
> begin sequence
> oWord
2009/3/26 Viktor Szakáts :
>> In my opinion gtwvt will be very useful for harbour user in windows 32
>
>>
>> xbase++ class & gtwvw is also a important bridge for Xbase developer
>> and xharbour+gtwvw
>> No support for ,windows ce,windows 64,linux but maybe wine ..is
>> similar situation to gtxwc,g
>
> In my opinion gtwvt will be very useful for harbour user in windows 32
> because allow a easy switch cui gui
You mean gtwvg, I guess.
> xbase++ class & gtwvw is also a important bridge for Xbase developer
> and xharbour+gtwvw
> No support for ,windows ce,windows 64,linux but maybe wine ..i
In my opinion gtwvt will be very useful for harbour user in windows 32
because allow a easy switch cui gui
xbase++ class & gtwvw is also a important bridge for Xbase developer
and xharbour+gtwvw
No support for ,windows ce,windows 64,linux but maybe wine ..is
similar situation to gtxwc,gtwvw
a docu
Hi Przemek,
I thought our way or working is that everytime we commit something
we enhance some parts of Harbour, rather than reintroducing some
known problems. I posted the exact error list to help develop a real
fix, instead of seeing your report repeated as a sort of answer.
I'd kindly ask you
Hi Przemek,
I see your point and I agree with HB_PATH_MAX, and making sure it's always
sized properly for all platforms.
But: doing so without including windows.h in all files. One
other solution is to add a Harbour API to retrieve this value,
or even to allocate a filename buffer at once. Both n
>
> I suggest moving to a example\olsolete path instead of remove (hbwhat,
> hbgf and hbsqlit2 )
> examples\unsupported or similar
If these parts are only a burden for I see no reason to use our
repository as a warehouse for obsolete / unsupported items.
F.e. every such code appear in all grep co
On Thu, 26 Mar 2009, Szak�ts Viktor wrote:
Hi,
> > * harbour/contrib/gtwvg/gtwvg.h
>! moved _WIN32_IE declaration before #include ... to fix MinGW32
> compilation
> After this, mingw64 fails with these messages (previously it compiled
> cleanly):---
> make -C gtwvg install
> make[2]: En
On Fri, 06 Feb 2009, Przemyslaw Czerpak wrote:
Hi,
> > We should IMO never include windows.h from hbdefs.h. Besides
> > slowing down build time to a great deal, we don't do this for other
> > OS APIs either. This would also suggest that Windows API usage
> > is freely allowed in any files, which
I suggest moving to a example\olsolete path instead of remove (hbwhat,
hbgf and hbsqlit2 )
examples\unsupported or similar
2009/3/26 :
> Revision: 10701
>
> http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10701&view=rev
> Author: vszakats
> Date: 2009-03-26 15:59:4
Thanks Angel. I agree with you.
If we indeed think this direction seriously we could make
some moves to separate portable and non-portable libs
from each other. Something should count as portable if
at least Windows (including x86, x64 and wince),
Linux and Darwin are supported. If more platforms a
Hi Francesco.
>do you use MSVC ? If yes, do you have tested same code after removing
>-TP flag in config/msvc.cf and rebuild entire SVN ?
No, I´m using BCC 6.10. New OLE seems work fine, except that
GetActiveObject() is not working, as I posted in my last sample.
Best regards,
Toninho.
_
Revision: 10701
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10701&view=rev
Author: vszakats
Date: 2009-03-26 15:59:44 + (Thu, 26 Mar 2009)
Log Message:
---
2009-03-26 16:58 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* INSTALL
- contrib/hbapo
I share the principle of Angel's view.
Focus is important.
Some similar kind of decisions was made by Ubuntu project when they started
their "fork" from Debian - they excluded some platforms which they considered
to be less in use.
Support of too many platform variants takes resources.
De
Hello Viktor:
Here's an outsider's point of view and vision about harbour.
This is a multiplattform compiler so in my personall point of view the
only c commpiler that should be guaranteed to work flawless is gcc/mingw.
Other compilers should be responsibility of special distros supporters.
Als
>
> * harbour/contrib/gtwvg/gtwvg.h
! moved _WIN32_IE declaration before #include ... to fix MinGW32
compilation
After this, mingw64 fails with these messages (previously it compiled
cleanly):---
make -C gtwvg install
make[2]: Entering directory `/c/work/harbour-new/harbour/contrib/gtw
Revision: 10700
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10700&view=rev
Author: druzus
Date: 2009-03-26 14:58:57 + (Thu, 26 Mar 2009)
Log Message:
---
2009-03-26 16:05 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
* harbour/contrib/hbole
Revision: 10699
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10699&view=rev
Author: vszakats
Date: 2009-03-26 14:55:04 + (Thu, 26 Mar 2009)
Log Message:
---
2009-03-26 15:54 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* utils/hbmk2/hbmk2.prg
Revision: 10698
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10698&view=rev
Author: vszakats
Date: 2009-03-26 14:48:15 + (Thu, 26 Mar 2009)
Log Message:
---
2009-03-25 15:47 UTC+0100 Viktor Szakats (harbour.01 syenar hu)
* doc/en/Makefile
* doc/M
Hi Toninho,
Il 26/03/2009 13.41, toni...@fwi ha scritto:
But with a more extensive test here I found that this code doesn´t
work:
---cut---
procedure testolenew()
local oWord, oText
begin sequence
oWord = GetActiveObject( "Word.Application" )
recover
begin sequence
Hi VIktor,
>Toninho, please provide a patch because I have no idea what
>HRESULT should be. An hbwinole.h is also needed if we
>want to publish C level functions. I'd appreciate if you could
>provide such patch and I will upload it.
I looked at my code and I think that HRESULT is not needed. A si
I totaly agree with your path
all all BCC/owatcom users will easy recompile harbour from source
better having userbase focaluzed on Two compiler that give more
reliability to entire project
2009/3/26 Viktor Szakáts :
>> Hi agree about importance of give a choice and agree mingw/msvc path
>> can w
Hi,
../../olecore.c(116) : error C2440: '=': impossibile convertire da 'void
*' a 'char *'
La conversione da 'void*' a puntatori a valori non 'void'
richiede un cast esplicito
Fixed.
../../olecore.c(134) : error C2039: 'n1': non Š un membro di 'tagVARIANT'
c:\program files\m
Revision: 10697
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=10697&view=rev
Author: snaiperis
Date: 2009-03-26 12:13:27 + (Thu, 26 Mar 2009)
Log Message:
---
2009-03-26 14:10 UTC+0200 Mindaugas Kavaliauskas (dbtopas/at/dbtopas.lt)
* harbour/contrib
Hi Chen,
no the problem is related to hbole itself, as I have tested without and
with -TP and error is the same (I'm missing to wrote it in my mail)
best regards,
Francesco
Il 26/03/2009 10.17, Chen Kedem ha scritto:
I confirm problem with msvc
I think its the same problem already reported
>
> Hi agree about importance of give a choice and agree mingw/msvc path
> can we follow Minigui that include harbour & MinGW to be ready to use
> for windows platform?
I don't know MiniGUI, so I cannot tell.
What is possible though is to provide such a binary distribution
which is based on Min
Hi agree about importance of give a choice and agree mingw/msvc path
can we follow Minigui that include harbour & MinGW to be ready to use
for windows platform?
it can be a strong messages for third parties libraries
we can cooperate (divide effort) with minigui project and
distribute/promote any
Hi Przemek,
You must be right. Since you know much better how
to fix these, please do whatever update needs to be done,
I have a limited knowledge of Windows API and all the
ugly details involved (MSDN is often not an answer), and
I'm not a user of it at all, nor interested in understanding its
"st
Yes, it's a problem, particularly when a lib is binary only.
The most affected platform is Windows, where there are
plenty of compilers with multiple CPUs, Unicode/non-Unicode,
C/C++ mode, plus - thank god... - WinCE.
Part of my effort is to find the "best" C compiler for Harbour.
We've started fr
Hi Francesco, Toninho,
Thanks for the feeback. I'm completely lost how to fix this
(except one obvious case) properly for C++ (bcc or msvc),
so I'd like kindly to ask OLE users to look into it. Apparently,
the method used in old code and hbwin will make it compile
in C++ mode, but it won't run.
To
> I confirm problem with msvc
I think its the same problem already reported with C++ mode
(the -TP switch) and some of the contribs
Chen.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
I confirm problem with msvc
Il 25 marzo 2009 23.17, Francesco Saverio Giudice
ha scritto:
>
> Hi Viktor, Mindaugas,
>
> Il 25/03/2009 20.00, Francesco Saverio Giudice ha scritto:
>>
>> Please wait until I (and probably other: Pritpal ?) will check if there
>> are problems with new and if we need
52 matches
Mail list logo
