[Harbour] SF.net SVN: harbour-project:[11085] trunk/harbour
Revision: 11085 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11085view=rev Author: vszakats Date: 2009-05-19 06:20:47 + (Tue, 19 May 2009) Log Message: --- 2009-05-19 08:19 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk2/hbmk2.pt_BR.po * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.prg + Displaying C compiler used (with path) if autodetection was used and -info enabled. ! Workaround added to MemoLine() sometimes returning empty string for the last line. * source/rtl/tget.prg % Minor opt. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/source/rtl/tget.prg trunk/harbour/utils/hbmk2/hbmk2.hu_HU.po trunk/harbour/utils/hbmk2/hbmk2.prg trunk/harbour/utils/hbmk2/hbmk2.pt_BR.po This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[11086] trunk/harbour
Revision: 11086 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11086view=rev Author: druzus Date: 2009-05-19 09:37:28 + (Tue, 19 May 2009) Log Message: --- 2009-05-19 11:46 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/contrib/xhb/xhbmsgs.c ! fixed one byte string as number emulation in some math operations where both expressions are one byte strings, f.e.: ? A * B Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/xhbmsgs.c This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
Szakáts Viktor wrote: Not just a habit, Harbour (and of course hbmk2) also supports DOS, and potentially other such limited OSes/filesystems where LFN isn't available. So in Harbour core we stick to 8.3 names. Perhaps it is time to drop support for those limits. I cannot imagine them pertaining to any development environment commonly in use today? This change would not stop anyone deploying to one of those OS's. The only one I can think of would be DOS. I would say the situation would be similar to cross-compiling for CE, I doubt anyone wants harbour to run on CE, just to deploy harbour apps to it. Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
On Tue, 19 May 2009, Alex Strickland wrote: Hi, Not just a habit, Harbour (and of course hbmk2) also supports DOS, and potentially other such limited OSes/filesystems where LFN isn't available. So in Harbour core we stick to 8.3 names. Perhaps it is time to drop support for those limits. I cannot imagine them pertaining to any development environment commonly in use today? I can. DOS is quite often used in embedded systems like extended barcode readers with small PC inside. It's nice that I can write applications for them in Harbour. I also knows some installations which still uses compters with DOS terminals. Please also note that the limitations comes from file system not OS. Most of popular mass storage devices are reformatted with FAT. They are very often used with some external devices f.e. physical printers which do not support VFAT, f.e. due to MS patents. It will not change in the nearest years. This change would not stop anyone deploying to one of those OS's. The only one I can think of would be DOS. I would say the situation would be similar to cross-compiling for CE, I doubt anyone wants harbour to run on CE, just to deploy harbour apps to it. I do not see any problem in using different names by user in his programs if he only wants it. But dropping 8.3 file name support in core code and forcing names which does not feet above condition because it looks nicer is not enough argument for me. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
Not just a habit, Harbour (and of course hbmk2) also supports DOS, and potentially other such limited OSes/filesystems where LFN isn't available. So in Harbour core we stick to 8.3 names. Perhaps it is time to drop support for those limits. I cannot imagine them pertaining to any development environment commonly in use today? This change would not stop anyone deploying to one of those OS's. The only one I can think of would be DOS. I would say the situation would be similar to cross-compiling for CE, I doubt anyone wants harbour to run on CE, just to deploy harbour apps to it. We allow to build Harbour on DOS, so it's not only a target at this moment. We also allow to build apps on DOS. Our target is still to keep Clipper compatibility and Clipper runs on DOS. I can imagine users who wouldn't want to switch directly to Windows/Linux, but first compile app for Harbour/DOS. Some ppl may even need to run apps in pure DOS environment. This also seems to be backed by sf.net download stats, where our DOS downloads rank quite high (also to my surprise). So for now I wouldn't agree to drop DOS support, just to introduce one long filename extension, otherwise the 8.3 isn't very pressing for Harbour IMO. Of course if other group members agree to drop DOS support, or partially drop DOS support as a build platform, we can do it. I personally don't need it. However we decide IMO there should be a pretty pressing need to introduce long extensions for our few basic file types, for me they look very strange in most cases, and in case of hbmk2 I most probably wouldn't use them. We will see, maybe there are some other good 3 char choices for .hbm/.hbp/.hbt. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
Przemyslaw Czerpak wrote: I can. DOS is quite often used in embedded systems like extended barcode readers with small PC inside. It's nice that I can write applications for them in Harbour. I also knows some installations which still uses compters with DOS terminals. Please also note that the limitations comes from file system not OS. Most of popular mass storage devices are reformatted with FAT. They are very often used with some external devices f.e. physical printers which do not support VFAT, f.e. due to MS patents. It will not change in the nearest years. I hear you, but, does anyone *develop* systems on those devices etc. I do not see any problem in using different names by user in his programs if he only wants it. But dropping 8.3 file name support in core code and forcing names which does not feet above condition because it looks nicer is not enough argument for me. It's not just nicer, Viktor was finding it difficult to come up with a technically elegant solution. Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
On Tue, 19 May 2009, Alex Strickland wrote: Hi, I can. DOS is quite often used in embedded systems like extended barcode readers with small PC inside. It's nice that I can write applications for them in Harbour. I also knows some installations which still uses compters with DOS terminals. Please also note that the limitations comes from file system not OS. Most of popular mass storage devices are reformatted with FAT. They are very often used with some external devices f.e. physical printers which do not support VFAT, f.e. due to MS patents. It will not change in the nearest years. I hear you, but, does anyone *develop* systems on those devices etc. I am. I also think that anyone here can write very simple .prg application customized for final user and install it in barcode reader to use it instead of a default one. He only need Harbour with pure console DOS support. I also think that any Harbour user may need write program which will have to exchange data or store all files in some storage device where pure FAT will be available only. I do not see any reason why we should forbid or reduce such possibilities. I do not see any problem in using different names by user in his programs if he only wants it. But dropping 8.3 file name support in core code and forcing names which does not feet above condition because it looks nicer is not enough argument for me. It's not just nicer, Viktor was finding it difficult to come up with a technically elegant solution. I think that you misunderstood him. best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed.
Hi! I get the error. Application Internal Error - C:\letodb\bin\letodb.exe Terminated at: 2009.05.18 17:22:09 Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed. Called from DBUSEAREA(0) Called from HS_OPENTABLE(390) in source\server\server.prg Called from LETO_SERVER(0) Called from STARTSERVER(239) in source\server\server.prg Called from MAIN(157) in source\server\server.prg My RDD is CDX, and i am using Harbour, SVN. My enviroment is: c:\dados\Dir01\clientes.dbf c:\dados\Dir02\clientes.dbf c:\dados\Dir03\clientes.dbf c:\dados\Dir04\clientes.dbf I need to know what file this with corrupted index and in that place(sub directory). The letodb not informed. This is the reply of Mr Alexander: Unfortunately, there is no possibility to know this. [x]Harbour doesn't allow to catch, to handle the internal error, it simply terminates the application. Theoretically, if there wasn't hardware problems, including power off, if the table and index are handled by Harbour only and the DBFCDX RDD hasn't errors, such kind of problems shouldn't appear. But if it appears, the only way is to reindex tables and restart the letodb. Regards, Alexander. I need to know which file is corrupted. Maybe: Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed. Called from DBUSEAREA(0) - c:\dados\Dir01\clientes.dbf. //So I know to fix the problem Regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
Przemyslaw Czerpak wrote: I hear you, but, does anyone *develop* systems on those devices etc. I am. Well, I can't argue with that then :). Regards Alex ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
Hi, I hear you, but, does anyone *develop* systems on those devices etc. I was. Though, it was C application, I did not know anything about Harbour that time. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors with 11032
Hi,
nAddr := MakeWndProc( {|X,Y,Z,T| WndProc( X,Y,Z,T ) } )
Can you make this function public. Probably this may pave the
way to clean a non-portable part of GTWVG, whio knows.
This function is not 64bit compatible. So, I do not want to propose it
for the masses. The source of it was published on [x]Harbour lists I
guess 2 or 3 times, in a few last years.
Just to put everything together, to have a whole picture:
Yes. It's OK, though I create
hWndAx := CreateWindow( ...
in the message handler of main windows on WM_CREATE message.
Regards,
Mindaugas
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed.
Client server not reduce data corruption? I am Using ads it is never crashed on server side (register error in log but non crash server) what appen if you Restart letodb executable on error and not use corrupted file 2009/5/19 Itamar Lins itamarl...@bol.com.br Hi! I get the error. Application Internal Error - C:\letodb\bin\letodb.exe Terminated at: 2009.05.18 17:22:09 Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed. Called from DBUSEAREA(0) Called from HS_OPENTABLE(390) in source\server\server.prg Called from LETO_SERVER(0) Called from STARTSERVER(239) in source\server\server.prg Called from MAIN(157) in source\server\server.prg My RDD is CDX, and i am using Harbour, SVN. My enviroment is: c:\dados\Dir01\clientes.dbf c:\dados\Dir02\clientes.dbf c:\dados\Dir03\clientes.dbf c:\dados\Dir04\clientes.dbf I need to know what file this with corrupted index and in that place(sub directory). The letodb not informed. This is the reply of Mr Alexander: Unfortunately, there is no possibility to know this. [x]Harbour doesn't allow to catch, to handle the internal error, it simply terminates the application. Theoretically, if there wasn't hardware problems, including power off, if the table and index are handled by Harbour only and the DBFCDX RDD hasn't errors, such kind of problems shouldn't appear. But if it appears, the only way is to reindex tables and restart the letodb. Regards, Alexander. I need to know which file is corrupted. Maybe: Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed. Called from DBUSEAREA(0) - c:\dados\Dir01\clientes.dbf. //So I know to fix the problem Regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[11087] trunk/harbour
Revision: 11087 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11087view=rev Author: vszakats Date: 2009-05-19 15:15:09 + (Tue, 19 May 2009) Log Message: --- 2009-05-19 17:10 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * utils/hbmk2/hbmk2.hu_HU.po * utils/hbmk2/hbmk2.prg + Added support for UTF-8 output. Currently on on *nix systems. The current solution is just an ugly hack, for the most part to test this problem in real life. The output format is also fixed to *nix OSes, there is not attempt made to detect terminal encoding, so it may be wrong if terminal expects something else. * utils/hbi18n/hbi18n.prg * .po_ - .po (Przemek, please verify me, or modify it as you think best) Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/utils/hbi18n/hbi18n.prg trunk/harbour/utils/hbmk2/hbmk2.hu_HU.po trunk/harbour/utils/hbmk2/hbmk2.prg This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
Alex Strickland wrote: Szakáts Viktor wrote: Not just a habit, Harbour (and of course hbmk2) also supports DOS, and potentially other such limited OSes/filesystems where LFN isn't available. So in Harbour core we stick to 8.3 names. Perhaps it is time to drop support for those limits. I cannot imagine them pertaining to any development environment commonly in use today? This change would not stop anyone deploying to one of those OS's. The only one I can think of would be DOS. I would say the situation would be similar to cross-compiling for CE, I doubt anyone wants harbour to run on CE, just to deploy harbour apps to it. Our primary goal is near 100% backwards compatibility with Clipper 5.2/5.3. That in itself means we need to support DOS. It's difficult to understand what the world wants to do with Harbour Project in the future. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Warning
Warning W8080 ../../sqlite3.c 105501: 'sqlite3one' is declared but never used EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Extensions - possible cleanup?
The compatibility regard that a source code clipper5.2/5.3 must run also without modification and not refered the original os environment (DOS) Now harbour have a lot of feature that clip52 not have: Command line compiler HBMK2 ,Multi Windows, Multi Thread, Multiplatform But also today we can have an application that be executed on fat16 disk on windows xp so we must sopport fat filesystem and not dos 2009/5/19 Phil Barnett ph...@philb.us Our primary goal is near 100% backwards compatibility with Clipper 5.2/5.3. That in itself means we need to support DOS. It's difficult to understand what the world wants to do with Harbour Project in the future. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Warning
I guess it comes from BCC, but I can't reproduce it with my installed versions. Anyhow it should be reported to sqlite3 developers for a fix, it won't cause any harm for Harbour. Brgds, Viktor On 2009.05.19., at 19:22, Enrico Maria Giordano wrote: Warning W8080 ../../sqlite3.c 105501: 'sqlite3one' is declared but never used EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Warning
-Messaggio Originale- Da: Szakáts Viktor harbour...@syenar.hu A: Harbour Project Main Developer List. harbour@harbour-project.org Data invio: martedì 19 maggio 2009 19.34 Oggetto: Re: [Harbour] Warning I guess it comes from BCC, but I can't reproduce it with my installed versions. Anyhow it should be reported to sqlite3 developers for a fix, it won't cause any harm for Harbour. Ok. EMG -- EMAG Software Homepage: http://www.emagsoftware.it The EMG's ZX-Spectrum Page: http://www.emagsoftware.it/spectrum The Best of Spectrum Games: http://www.emagsoftware.it/tbosg The EMG Music page: http://www.emagsoftware.it/emgmusic ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors with 11032
Hello Mindaugas
Mindaugas Kavaliauskas wrote:
nAddr := MakeWndProc( {|X,Y,Z,T| WndProc( X,Y,Z,T ) } )
Can you make this function public. Probably this may pave the
way to clean a non-portable part of GTWVG, whio knows.
This function is not 64bit compatible. So, I do not want to propose it
for the masses. The source of it was published on [x]Harbour lists I
guess 2 or 3 times, in a few last years.
I have tried to search for it but could not.
can you point-out the link, or to be easier, post on this list again.
I just want to compare with contrib/gtwvg/wincallb.c.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/Errors-with-11032-tp23521549p23622741.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors with 11032
Hi, I have tried to search for it but could not. can you point-out the link, or to be easier, post on this list again. I just want to compare with contrib/gtwvg/wincallb.c. I'd rather say wvg's is better. It uses VirtualAlloc() to allocate page having the correct (read/write/execute) permissions. But I'm lost among the details. _AsCallback() has many strange parameters instead of a single codeblock. The problem is I'm to lazy to change a working code. Win32 allows execute code on memory allocated using hb_xgrab(), so, this solution is Intel x86 Win 32bit only. I do not want to publish my code until it is dirty. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] HB_VALTOEXP
Hi, HB_VALTOEXP() works bad if object overloads enum operator. F.e., if I pass HB_OleAuto object, it gives RTE, since the specified class is not a collection and enum is overloaded. Using FOR and array access instead of FOR EACH seams to be bad solution, since array access can also be overloaded. It would be nice if HB_VALTOEXP() can use some internal function to drop class handle and write object as plain array. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How can create a library with hbmk2?
Massimo Belgrano escribió: hbmk2 myprg.PRG myprg2.PRG -hblib -omylib.lib Thank you Massimo, I have just discovered in a previous post of yours and it works fine. Best Regards GVS ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors with 11032
Hi Mindaugas Kavaliauskas wrote: I'd rather say wvg's is better. It uses VirtualAlloc() to allocate page having the correct (read/write/execute) permissions. But I'm lost among the details. _AsCallback() has many strange parameters instead of a single codeblock. Me too do not have any idea about its internals, but it works correct. The problem is I'm to lazy to change a working code. Win32 allows execute code on memory allocated using hb_xgrab(), so, this solution is Intel x86 Win 32bit only. I do not want to publish my code until it is dirty. NP, take your own time to clean it. Now some issues with plain CreateObject() function. I am using CodeJock's Calender Control. It has many interfaces and then it binds control with the interfaces. The code goes like this: oCal := hb_ActiveX( ... ) .. .. oDialogs := CreateObject( Codejock.CalendarDialog.11.2.2 ) ? valtype( oDialogs ) // O oDialogs:calendar := oCal -Here it GPF's Investigating deep I find ? valtype( oDialogs:calendar ) - U What I assume that some interfaces do not suppot IID_Dispatch, may be it is IID_Unknown, I am not sure. Extending above: ? valtype( oDialogs:ParentHWND ) - 0Correct So I am lost why some properties are accessible while others not. With previous implementation everything was fine. Then I tried to implement pDisp-lpVtbl-AddRef( pDisp ); but it does not work on hb_oleParam(), probably it expects numeric handle. Regards Pritpal Bedi Can we implement -- View this message in context: http://www.nabble.com/Errors-with-11032-tp23521549p23624655.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed.
Hi! Thanks for response, but ADS is ... for me. :-( I need to know which file is corrupted. Maybe: Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed. Called from DBUSEAREA(0) - c:\dados\Dir01\clientes.dbf. //So, can correct the correct file. Regards, Itamar M. Lins Jr. Massimo Belgrano mbelgr...@deltain.it escreveu na mensagem news:609353e70905190722j75effd3cv99d43f2305e7e...@mail.gmail.com... Client server not reduce data corruption? I am Using ads it is never crashed on server side (register error in log but non crash server) what appen if you Restart letodb executable on error and not use corrupted file 2009/5/19 Itamar Lins itamarl...@bol.com.br Hi! I get the error. Application Internal Error - C:\letodb\bin\letodb.exe Terminated at: 2009.05.18 17:22:09 Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed. Called from DBUSEAREA(0) Called from HS_OPENTABLE(390) in source\server\server.prg Called from LETO_SERVER(0) Called from STARTSERVER(239) in source\server\server.prg Called from MAIN(157) in source\server\server.prg My RDD is CDX, and i am using Harbour, SVN. My enviroment is: c:\dados\Dir01\clientes.dbf c:\dados\Dir02\clientes.dbf c:\dados\Dir03\clientes.dbf c:\dados\Dir04\clientes.dbf I need to know what file this with corrupted index and in that place(sub directory). The letodb not informed. This is the reply of Mr Alexander: Unfortunately, there is no possibility to know this. [x]Harbour doesn't allow to catch, to handle the internal error, it simply terminates the application. Theoretically, if there wasn't hardware problems, including power off, if the table and index are handled by Harbour only and the DBFCDX RDD hasn't errors, such kind of problems shouldn't appear. But if it appears, the only way is to reindex tables and restart the letodb. Regards, Alexander. I need to know which file is corrupted. Maybe: Unrecoverable error 1010: hb_cdxIndexPageRead: Read index page failed. Called from DBUSEAREA(0) - c:\dados\Dir01\clientes.dbf. //So I know to fix the problem Regards, Itamar M. Lins Jr. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano -- ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How can create a library with hbmk2?
Guillermo Varona Silupú wrote: Massimo Belgrano escribió: hbmk2 myprg.PRG myprg2.PRG -hblib -omylib.lib Thank you Massimo, I have just discovered in a previous post of yours and it works fine. Best Regards GVS ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour Does this also work? hbmk2 @myprglist.txt -hblib -omylib.lib I don't have an installation to test just now. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] How can create a library with hbmk2?
Does this also work? hbmk2 @myprglist.txt -hblib -omylib.lib Yes, it does. Also 'hbmk2 *.prg -hblib -omylib' works. I'd (again) recommend not to explicitly add .lib extension, as it makes the command line compiler and platform dependent. This is portable and simpler: 'hbmk2 @myprglist.txt -hblib -omylib' Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] ActiveX names
Hi, I've successfully implemented ActiveX notification event support from scratch. All code is 200 lines of C. I want to talk about names for all OLE/ActiveX things. What prefixes should be used for objects, methods, functions, etc? --- Question 1: Minimal method namespace polution --- Current implementations is: CLASS HB_OleAuto VAR __hObj VAR __hObjEnum ENDCLASS Previous class used TOleAuto and hObj, pOleEnumerator. It also used :New() constructor, some other 22 methods. My argument for __hObj is: HB_OleAuto is used to call methods of OLE objects. If HB_OleAuto has defined some methods, OLE methods having the same name could not be reached! F.e., TOleAuto() can not call :New() method of original OLE object. I even used HB_CLS_NOTOBJECT define to avoid inheritance from HBObject and leave method namespace as clean as possible. --- Question 2: No HB_ActiveX, because it's the same HB_OleAuto --- I think it is logical to continue the same approach in ActiveX. My current implementation of HB_ActiveX is: CLASS HB_ActiveX FROM HB_OleAuto VAR __hSink ENDCLASS Nothing more! HB_ActiveX also uses OLE automation to reach original methods so I want to keep its methods namespace clean. If __hSink if the only additional memeber, I'm thinking about adding it to HB_OleAuto. In this case we will have the same HB_OleAuto class for ActiveX controls. What is your opinion? Do we need a separate class? Actually HB_ActiveX is nothing more than HB_OleAuto if I do not use event handler to handle messages sent by OLE/ActiveX control to Harbour. If you look at my sample sent yesterday, it has: hWndAx := CreateWindowEx(WS_EX_CLIENTEDGE, ATLAXWin, ... HB_AtlAxGetControl( hWndAx, @pDisp ) IF ! EMPTY( pDisp ) oAx := HB_OleAuto() oAx:__hObj := pDisp ENDIF As you can see I've used HB_OleAuto with ActiveX control. But I do not defined any event handler, so I did not need any :__hSink. So, this HB_ActiveX is exactly HB_OleAuto. --- Question 3: Function names for OLE --- We have: * GetActiveObject - .prg function uses OLEGETACTIVEOBJECT returns HB_OleAuto object if object can be obtained; * CreateObject - .prg function uses OLEGETACTIVEOBJECT returns HB_OleAuto object if object can be obtained; * OLECREATEOBJECT returns Pointer.IDispatch; * OLEGETACTIVEOBJECT returns Pointer.IDispatch; * OLERELEASE releases object using Pointer.IDispatch (I'm thinking about removing this function, since collectible pointers do the job, ant it is a kind of internal function which should be marked as DO NOT USE); * __OLEENUMCREATE returns Pointer.IEnumIterator; * __OLEENUMNEXT uses Pointer.IEnumIterator to skip on next item; * OLEERROR, OLEERRORTEXT returns error code ant text for OLE errors. Since we are in very unstable state, I guess it is time to decide that name should be used in Harbour. Thus making a stable background for changes in 3rd party projects like FiveWin. The developer should use GetActiveObject, CreateObject, OleError and OleErrorText. Do we need HB_* prefix? GetActiveObject and CreateObject has VERY general name, shouldn't it belong to some OLE* prefixed namespace? All other are a kind of internal. From this point of view OLECREATEOBJECT should has two underscores just like __OLEENUMCREATE. So, the final names could be: HB_OleGetActiveObject - GetActiveObject HB_OleCreateObject- OleCreateObject HB_OleError - OLEERROR HB_OleErrorText - OLEERRORTEXT __OLECREATEOBJECT - OLECREATEOBJECT __OLEGETACTIVEOBJECT - OLEGETACTIVEOBJECT __OLEENUMCREATE is ok __OLEENUMNEXT is ok --- Question 4: Function names for ActiveX --- My current not yet committed ActiveX code has three functions: * HB_AtlAxInit - it's AtlAxInit from atl.dll plus dynamic loading of that .dll plus some more initialisation; * HB_AtlAxGetControl - it's AtlAxGetControl from atl.dll plus IDispatch interface request (since we are not going to work with IUnknown, and I want to hide conversion inside the same function making interface simple); * __AxRegisterHandler - this function is not a member of atl.dll. It registers codeblock or function symbol for event notification. It would be nice to have a nice prefixed naming for these functions in similar way as OLE functions. The first two has HB_ prefixed C function names, but it acts a little different, it is not just a wrappers and do more. It also return OLE error code, but I'm thinking about generating RTE on error and returning result collectible pointer or NIL. In OLE code the functions returning pointer has __* prefix (are internal). I'm thinking about (Ax is for ActiveX): HB_AxInit - HB_AtlAxInit __AxGetControl - HB_AtlAxGetControl __AxRegisterHandler is ok But if you compare these names to proposed above OLE function names, the last two returns pointers instead of final ActiveX object, so it should have __* prefix instead of HB_*. The final ActiveX function (not internal, without underscores) will
Re: [Harbour] Errors with 11032
Hi, oCal := hb_ActiveX( ... ) .. .. oDialogs := CreateObject( Codejock.CalendarDialog.11.2.2 ) ? valtype( oDialogs ) // O oDialogs:calendar := oCal -Here it GPF's I do not know the reason for without a deeper debugging. What is result of: ? oCal:ClassName Current code converts only HB_OLEAUTO class to VT_DISPATCH parameter, but I'm going to change it use a class inherited from HB_OLEAUTO, thus, making CLASS TOleAuto FROM HB_OleAuto available for passing as IDispatch variant parameter. Investigating deep I find ? valtype( oDialogs:calendar ) - U What I assume that some interfaces do not suppot IID_Dispatch, may be it is IID_Unknown, I am not sure. Extending above: ? valtype( oDialogs:ParentHWND ) - 0Correct So I am lost why some properties are accessible while others not. With previous implementation everything was fine. What is result of ? valtype( oDialogs:calendar ) in previous version. Then I tried to implement pDisp-lpVtbl-AddRef( pDisp ); but it does not work on hb_oleParam(), probably it expects numeric handle. I'm not sure that you mean. hb_oleParam() returns IDispatch, and AddRef() could be called. Regards, Mindaugas ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ActiveX names
Hi Mindaugas, I've successfully implemented ActiveX notification event support from scratch. All code is 200 lines of C. I want to talk about names for all Sounds very nice. OLE/ActiveX things. What prefixes should be used for objects, methods, functions, etc? --- Question 1: Minimal method namespace polution --- Current implementations is: CLASS HB_OleAuto VAR __hObj VAR __hObjEnum ENDCLASS Previous class used TOleAuto and hObj, pOleEnumerator. It also used :New() constructor, some other 22 methods. My argument for __hObj is: HB_OleAuto is used to call methods of OLE objects. If HB_OleAuto has defined some methods, OLE methods having the same name could not be reached! F.e., TOleAuto() can not call :New() method of original OLE object. I even used HB_CLS_NOTOBJECT define to avoid inheritance from HBObject and leave method namespace as clean as possible. Strictly speaking HB_OLEAUTO should be in the WIN_ namespace, so WIN_OLE would be the compliant class name, maybe now it's a good time to change it, if we depart from TOleAuto anyway. We already have WIN_PRN and WINPRT (should be WIN_PORT). [ HB_* is for core, WIN_* is for Windows specific stuff, WAPI_* if for API bindings. ] As for methods I think '__' prefix, or 'HB_' prefix (or both) is fine to avoid collision. --- Question 2: No HB_ActiveX, because it's the same HB_OleAuto --- I think it is logical to continue the same approach in ActiveX. My current implementation of HB_ActiveX is: CLASS HB_ActiveX FROM HB_OleAuto VAR __hSink ENDCLASS Nothing more! My vote to WIN_ACTIVEX or WIN_AX. HB_ActiveX also uses OLE automation to reach original methods so I want to keep its methods namespace clean. If __hSink if the only additional memeber, I'm thinking about adding it to HB_OleAuto. In this case we will have the same HB_OleAuto class for ActiveX controls. What is your opinion? Do we need a separate class? Just a light opinion here: A separate name could better emphasis this feature and users may more easily find it. --- Question 3: Function names for OLE --- We have: * GetActiveObject - .prg function uses OLEGETACTIVEOBJECT returns HB_OleAuto object if object can be obtained; * CreateObject - .prg function uses OLEGETACTIVEOBJECT returns HB_OleAuto object if object can be obtained; * OLECREATEOBJECT returns Pointer.IDispatch; * OLEGETACTIVEOBJECT returns Pointer.IDispatch; * OLERELEASE releases object using Pointer.IDispatch (I'm thinking about removing this function, since collectible pointers do the job, ant it is a kind of internal function which should be marked as DO NOT USE); * __OLEENUMCREATE returns Pointer.IEnumIterator; * __OLEENUMNEXT uses Pointer.IEnumIterator to skip on next item; * OLEERROR, OLEERRORTEXT returns error code ant text for OLE errors. Since we are in very unstable state, I guess it is time to decide that name should be used in Harbour. Thus making a stable background for changes in 3rd party projects like FiveWin. Good point. I'd try to apply the WIN_/WAPI_ rules to these names as much as possible, inside the WIN_ namespace we have full freedom to form names, so it can be WIN_OLE*(). We can also use the internal namespace for appropriate functions, but for public functions exposed to users I'd say we shouldn't use them. The developer should use GetActiveObject, CreateObject, OleError and OleErrorText. Do we need HB_* prefix? GetActiveObject and CreateObject has VERY general name, shouldn't it belong to some OLE* prefixed namespace? IMO they should. Strictly speaking these should be: WIN_OLEGETACTIVEOBJECT() WIN_OLECREATEOBJECT() WIN_OLEERROR() WIN_OLEERRORTEXT() For C level we have no such rule yet, and the considerations are a little bit different, so for these we should probably also use an hb_ prefix instead of win_. And this is what we use now AFAIK, so it's okay. All other are a kind of internal. From this point of view OLECREATEOBJECT should has two underscores just like __OLEENUMCREATE. So, the final names could be: HB_OleGetActiveObject - GetActiveObject HB_OleCreateObject - OleCreateObject HB_OleError - OLEERROR HB_OleErrorText - OLEERRORTEXT __OLECREATEOBJECT - OLECREATEOBJECT __OLEGETACTIVEOBJECT - OLEGETACTIVEOBJECT __OLEENUMCREATE is ok __OLEENUMNEXT is ok (see above) What are we using these __ prefixed ones for? --- Question 4: Function names for ActiveX --- My current not yet committed ActiveX code has three functions: * HB_AtlAxInit - it's AtlAxInit from atl.dll plus dynamic loading of that .dll plus some more initialisation; * HB_AtlAxGetControl - it's AtlAxGetControl from atl.dll plus IDispatch interface request (since we are not going to work with IUnknown, and I want to hide conversion inside the same function making interface simple); * __AxRegisterHandler - this function is not a member of atl.dll. It registers codeblock or function symbol for event notification. It would be nice to have
[Harbour] SF.net SVN: harbour-project:[11088] trunk/harbour
Revision: 11088 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=11088view=rev Author: vszakats Date: 2009-05-19 23:49:17 + (Tue, 19 May 2009) Log Message: --- 2009-05-20 01:39 UTC+0200 Viktor Szakats (harbour.01 syenar hu) * INSTALL * Minor update to Pelles C version support. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ActiveX names
Hi I've successfully implemented ActiveX notification event support from scratch. All code is 200 lines of C. WOW. Unbelievable! Whatever way you think is right, go, though Viktor suggessions are also valid. My understanding of OLE implementation is as: CreateObject() GetActiveObject() is widely used functions in almost all the languages. These two functions implement non-rectangular COM objects or those object whech have their own user-interfaces like Excel, Word, etc. And I would like to keep them as is. To avoid colision with current code, to start with we can give them whatever prefix you deem fit - HB_* or WIN_* but after these are tested we need to rename them to CreteObject() and GetActiveObject(). ActiveX Control is one which is hosted in the window provided by the application. So you are completely free to implement in whatever way you want. Just make sure that those could be obtained via a function call. I am really thrilled and looking forward to feel the code. Regards Pritpal Bedi -- View this message in context: http://www.nabble.com/ActiveX-names-tp23625955p23626853.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] ActiveX names
is widely used functions in almost all the languages. These two functions implement non-rectangular COM objects or those object whech have their own user-interfaces like Excel, Word, etc. And I would like to keep them as is. To avoid colision with current code, to start with we can give them whatever prefix you deem fit - HB_* or WIN_* but after these are tested we need to rename them to CreteObject() and GetActiveObject(). We will create these compatibility aliases, but let's please stick to our rules for new functions. We've already agreed on them once, and it would be very important to aim to some direction I've been talking about just a day ago and which I miss from many Windows specific parts in Harbour. It would look quite strange to forgot about these rules as soon as we'd actually apply them in practice. CreateObject and also GetActiveObject are so vague, that it's quite easy to collide with them. Moreover, it's useful to see where a function comes from, especially when those functions are non-portable ones. WIN_ signals that clearly, these names by themselves don't. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors with 11032
Hi
? valtype( oDialogs:calendar ) - U
This is OK as at this point :calendar property is uninitialized.
oDialogs:calendar := oCal -GPF
If I omit above line then Calandar Control behaves properly.
I just cannot open any of the dialogs provided by the control.
Later one more error is generated but so far I am concentrating
upto this point.
It also implies that oCal is initialized properly.
oDialog is also intialized properly but do not accept oCal.
May be this gives a clue.
? HB_Atl_AddRef( oCal:__hObj ) - 6 == INVALID HANDLE ???
HB_FUNC( HB_ATL_ADDREF )
{
IDispatch *pDisp = ( IDispatch * ) hb_oleParam( 1 );
HRESULT hr = pDisp-lpVtbl-AddRef( pDisp );
hb_retni( ( int ) hr );
}
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/Errors-with-11032-tp23521549p23627409.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Extensions - possible cleanup?
Alex Strickland wrote: I hear you, but, does anyone *develop* systems on those devices etc. You'd be surprised to see how many account software exist running over only DOS and most of the Banks (CIT*, HSB*, etc) have several system running on old DOS7 and Novell networks. I know it's really difficult to imagine that, but is true, at least in Latin america and I suppose..., in many other countries of the world. Sometimes we assume that other people needs are the same as ours I am still suscribed to old Clipper groups, and you wonder how many developers have not yet migrated to a GUI environment. I can't say that this is good or bad, just happens. Alejandro _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Errors with 11032
Hello
I was experimenting and got to this point : olecore.c line # 231
case HB_IT_OBJECT: /* or ARRAY */
if( HB_IS_OBJECT( pItem ) )
{
// if( hb_stricmp( hb_objGetClsName( pItem ), HB_OLEAUTO ) == 0 )
^
{
IDispatch * pDisp;
hb_vmPushDynSym( s_pDyns_hObjAccess );
hb_vmPush( pItem );
hb_vmSend( 0 );
pDisp = hb_oleParam( -1 );
/* pVariant will be freed using VariantClear().
We increment reference count to keep OLE object alive */
#if HB_OLE_C_API
pDisp-lpVtbl-AddRef( pDisp );
#else
pDisp-AddRef();
#endif
pVariant-n1.n2.vt = VT_DISPATCH;
pVariant-n1.n2.n3.pdispVal = pDisp;
}
}
If I comment out line # 231 as above
oDialogs:calendar := oCal works fine and I can open the dialogs.
You can see that the object is issued AddRef().
May it help you understanding what is happening.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/Errors-with-11032-tp23521549p23628301.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
