[Harbour] achoice hack?
Hi, Base from dbu's menu system the following hack will fix freezing dropdown menus. 130: lFinished := ( nMode == AC_NOITEM ) // just insert this block IF lFinished IF lUserFunc Do( xUserFunc, nMode, nPos, nPos - nAtTop ) ENDIF ENDIF // end block DO WHILE !lFinished -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
RE:[Harbour] extern / contrib to parse excel files?
Hi smu, You just need hbwin to create an ole object. local xls := win_OleCreateObject(Excel.Application). xls:Open() xls:Close() Best Regards, Jerry -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SMB1 and SMB2
Dear friends, can you tell me if there are any known issues with Harbour and Microsoft's Server Message Block technology? It is a caching technology which will delay the writing of data to shared files on a Windows server. SMB2 is new with Server 2008 and Vista / Windows 7 clients. I'm wondering if that technology will obey dbCommit() commands in Harbour, or if it simply ignores them. Thank you. 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 (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] ACHOICE() bug for 2010, with simple hello world example
Hi,
Here is a proven section of code to denote a Harbour / Clipper achoice()
difference. From looking at the difference, I believe it is a simple fix.
But this I cannot guarantee (yet).
Anyways, the code + comments will summarize everything. But in a nutshell,
it is this: the cursor position of the called function doesn't always show
up vertically where the choice selection is.
Thank you in advance for taking a concern in this.
___CODE:___
// The seconds() should appear to the right of the currently highlighted row
// This works until you arrow past the top of the list or use the right/left
arrows, in which case it
// always uses the last row of the screen coordinates to print the seconds.
// In this program, there are only 5 rows for 10 letters of the alphabet, so
in the case described above,
// it will always print the seconds on the 5th (bottom) row when left/right
is hit, or the top array
// value (a) is reached.
// For others' curiosity sake, I found this bug because in my program I am
trying to highlight an item in red,
// or position a get text field on the row they are on.
// This has been tested in Harbour and CL52e, and Clipper does it correctly
where the seconds() printed text is not
// positioned incorrectly.
Func main()
cls
a:={a,b,c,d,e,f,g,h,i,j}
x:=achoice(1,1,5,20,a,NIL,myfunc)
Return Nil
Func Myfunc()
setpos(row(),Col()+20)
devout(str(seconds()))
if lastkey()=13
x:=1
ELSE
x:=2
endif
return x
--
smu johnson smujohn...@gmail.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:[14415] trunk/harbour
Revision: 14415 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14415view=rev Author: druzus Date: 2010-04-30 09:39:25 + (Fri, 30 Apr 2010) Log Message: --- 2010-04-30 11:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbznet.c ! fixed stupid typo which caused that hb_znetFlush() in encrypted buffers never returned 0 (the returned value was increased by 4) * harbour/contrib/hbnetio/netio.h * harbour/contrib/hbnetio/netiocli.c * harbour/contrib/hbnetio/netiosrv.c * harbour/contrib/hbnetio/readme.txt + added support for communication streams/channels which allow to send asynchronously data from server to client. The following client side functions had been added: NETIO_OPENDATASTREAM( cStreamFuncName [, params,...] ) - nStreamID NETIO_OPENITEMSTREAM( cStreamFuncName [, params,...] ) - nStreamID NETIO_CLOSESTREAM( nStreamID, [cServer], [nPort] ) - lOK NETIO_GETDATA( nStreamID, [cServer], [nPort] ) - aData | cData | NIL The following server side functions had been added: NETIO_SRVSTATUS( pConnectionSocket [, nStreamID] ) - nStatus NETIO_SRVSENDITEM( pConnectionSocket, nStreamID, xData ) - lSent NETIO_SRVSENDDATA( pConnectionSocket, nStreamID, cData ) - lSent + added RT errors to the netio client code. They should help to early detect any communication problems ! disabled hb_socketSetNoDelay() in client and server code. I enabled it for some local tests and by mistake committed to SVN and I didn't noticed it. It could cause serious problems in some cases i.e. with slow WiFi or WAN connections. Warning: server signature changed due to extensions in protocol. both client and server side has to be updated and use current SVN code. + harbour/contrib/hbnetio/tests/netiot03.prg + added demonstration/test code for alternative RDD IO API, RPC and asynchronous data streams in HBNETIO Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbnetio/netio.h trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/hbnetio/readme.txt trunk/harbour/src/rtl/hbznet.c Added Paths: --- trunk/harbour/contrib/hbnetio/tests/netiot03.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: Netio Questions
Alex Strickland wrote: If the server is stopped (quit), the client stays frozen, it doesn't time out. Or am I doing something wrong here? I just started looking at the code: NETIO_CONNECT( [cServer], [nPort], [nTimeOut], ; [cPasswd], [nCompressionLevel], [nStrategy] ) nTimeOut defaults to -1 if you don't set it, and I guess that means no timeout. Note, I haven't run any code or confirmed my guess by digging deeper. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi, I see no problem for Win 3.x and Win32s, we still have customers with Win9x. Many of the projects are contained in the only .exe file, so requirement of extra .dll is not nice. One more thing is that my libraries are non-UNICODE, but I do not see a big reason to do rewrite a working piece of code until HVM internals does not allow to contain multi-language strings and rewrite do not add new fuctionality. Maybe some macros like HB_PARSTR() can help to implement a good layer for UNICODE/non-UNICODE versions of app. It can help to make code clean and easy maintainable. Regards, Mindaugas On 2010.04.29 15:13, Viktor Szakáts wrote: If that simplifies things (which it definitely does), and the majority of developers agree with it, we can drop non-UNICODE mode altogether from Harbour source code. It's unlikely we shall ever support Windows 3.x or Win32s, and unicows solution works just perfect now to cover Win9x/ME host versions, so I can see no hard reason to maintain duplicate code paths for both UNICODE and non-UNICODE Windows API support. Having only UNICODE path could greatly simplify code in many crucial points, making it easier to maintain, extend, debug and keep bug free. Especially if we want to move towards internal (HVM) unicode support in the future. Any opinions on this? ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Mindaugas, I see no problem for Win 3.x and Win32s, we still have customers with Win9x. Many of the projects are contained in the only .exe file, so requirement of extra .dll is not nice. One more thing is that my libraries are non-UNICODE, but I do not see a big reason to do rewrite a working piece of code until HVM internals does not allow to contain multi-language strings and rewrite do not add new fuctionality. Pls remember that you may well need other extra .dlls/packages anyway f.e. to run Harbour apps on Win95/Win95b and other combinations, like mingw/msvc builds and Win95-98. Chances are high though that unicows.dll and these other extra packages are already installed by now (had 12-15 years to do that), if not, there are simple MS packages users can install on these PCs. My point is that it's unavoidable anyway to deal with the extra package issue when running Harbour apps (and many other apps) on Win9x, and that such issue is not very hard to deal with, since there exist official MS package for all of them, and the packages are well documented even in our INSTALL doc. Other libs and local code are unaffected by Harbour core's UNICODE mode. So while I see your point, this is not something which has any technical influence on our decision. Maybe some macros like HB_PARSTR() can help to implement a good layer for UNICODE/non-UNICODE versions of app. It can help to make code clean and easy maintainable. It covers part of the problem, but doesn't cover other 200 code sections, where these functions cannot be used. These are usually code sections which deal with the conversions on the low level (as opposed to simply accept/return Harbour function parameters, like with HB_PARSTR() and friends). 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:[14415] trunk/harbour
Hi, On 2010.04.30 12:39, dru...@users.sourceforge.net wrote: + added support for communication streams/channels which allow to send asynchronously data from server to client. The following client side functions had been added: NETIO_OPENDATASTREAM(cStreamFuncName [,params,...] ) - nStreamID NETIO_OPENITEMSTREAM(cStreamFuncName [,params,...] ) - nStreamID NETIO_CLOSESTREAM(nStreamID, [cServer], [nPort] ) - lOK NETIO_GETDATA(nStreamID, [cServer], [nPort] ) - aData |cData | NIL The following server side functions had been added: NETIO_SRVSTATUS(pConnectionSocket [,nStreamID] ) - nStatus NETIO_SRVSENDITEM(pConnectionSocket,nStreamID,xData ) - lSent NETIO_SRVSENDDATA(pConnectionSocket,nStreamID,cData ) - lSent Thank You for another great piece of code. I'm trying to understand the ideas of this. In case of item stream, received items are buffered on client side and NETIO_GETDATA() return array of items. In case of char stream, data is concatenated and NETIO_GETDATA() return a single stream. Function NETIO_GETDATA() is not blocking function and returns NIL if no data are received. Am I right? You've mentioned in the past, that these communication streams allows server application to give access to local resources like COM ports, etc. In most cases, f.e. COM port, communication is bidirectional, but I found communication stream unidirectional (from server to client). How do you suggest to do data transfer in the opposite direction? In the sample code, the communication streams are closed after NETIO_DISCONNECT(). Is data transfer allowed in between of NETIO_DISCONNECT() and NETIO_CLOSESTREAM() calls? Are connection stream ids unique among multiple connection? As far as I can see, each connection has it's own connection ideas, and this requires to use additional cServer and nPort parameters to distinguish different connections. I see s_fileGetConnParam(), hb_socketResolveAddr(), s_fileConFind() in NETIO_GETDATA(). Isn't this a bottleneck for applications what needs a lot of data transfers? The same question for RPC calls. Thanks again, regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Error BASE/1099 Argument error: STR
Hi Viktor, I don't understand how to implement follow line Rather use -i option or point to xhb.hbc file. (or simply copy your sample to contrib/xhb/tests/ dir and issue hbmk2 from there) I also tried all the suggestions figure out but unfortunatly it doesn't work: The mistake is: Compiling 'xml1.prg'... xml1.prg(17) Warning W0001 Ambiguous reference 'TXMLDOCUMENT' No code generated. hbmk2: Error: Running Harbour compiler (embedded). 1 (/usr/bin/harbour) -n2 xml1.prg -w3 -es2 -o/tmp/ -i/usr/include/harbour -i.. -i../../hbct -i../../hbtip -i/usr/local/lib/harbour Thanks in advance Ivan ___ 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:[14408] trunk/harbour
HI Viktor I don't understand if I had to download hbxml.c and use it. I don't understand how to use it. TIA Ivan On Wed, Apr 28, 2010 at 11:12 PM, vszak...@users.sourceforge.net wrote: Revision: 14408 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14408view=rev Author: vszakats Date: 2010-04-28 21:12:17 + (Wed, 28 Apr 2010) Log Message: --- 2010-04-28 23:11 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/xhb/hbxml.c ! REVERTED: 2010-04-05 11:04 UTC+0200 This means that these heavy leaks are again present in this xhb ported code, but at least it won't GPF. * contrib/xhb/tests/xml1.prg ! Minor to prev. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/hbxml.c trunk/harbour/contrib/xhb/tests/xml1.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:[14408] trunk/harbour
I think that viktor say that try to test your sample in test folder in order to hbmk2 use the hbmk config file from tests samples Copy your prg to xhb test folder and try to compile without use any option only hbmk2 your_prg and make sure that hbmk.hbm file is present Bruno 2010/4/30 ivan re re.i...@gmail.com HI Viktor I don't understand if I had to download hbxml.c and use it. I don't understand how to use it. TIA Ivan On Wed, Apr 28, 2010 at 11:12 PM, vszak...@users.sourceforge.net wrote: Revision: 14408 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14408view=rev Author: vszakats Date: 2010-04-28 21:12:17 + (Wed, 28 Apr 2010) Log Message: --- 2010-04-28 23:11 UTC+0200 Viktor Szakats (harbour.01 syenar.hu) * contrib/xhb/hbxml.c ! REVERTED: 2010-04-05 11:04 UTC+0200 This means that these heavy leaks are again present in this xhb ported code, but at least it won't GPF. * contrib/xhb/tests/xml1.prg ! Minor to prev. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/xhb/hbxml.c trunk/harbour/contrib/xhb/tests/xml1.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 ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
Enrico, do a search on past messages. There was a person that had several serious issues with smb2. From memory, he solved applyuing a security patch that allowed to disable smb2... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
On Fri, Apr 30, 2010 at 9:43 AM, Enrico Maria Giordano e.m.giord...@emagsoftware.it wrote: Dear friends, can you tell me if there are any known issues with Harbour and Microsoft's Server Message Block technology? It is a caching technology which will delay the writing of data to shared files on a Windows server. SMB2 is new with Server 2008 and Vista / Windows 7 clients. I'm wondering if that technology will obey dbCommit() commands in Harbour, or if it simply ignores them. I've found some msgs about it. In my gmail the first reference is: 2009-12-06 13:30 UTC+1200 Peter Rees peter(AT)rees.co.nz * source\rtl\winos.prg + OS_ISWINVISTA_OR_LATER() - .t. if osvi.dwMajorVersion = 6 * Update OS_NETREGOK() for Vista,Win2008 Win7 SMB2 is required to be turned off on Server best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
From a thread started by smu johnson on March 3 Well we have a ton of people who still use Windows, and because of that we need a Windows solution. I am happy to report that after about 30 mins of Googling, I came across this page, which solved the problem, if you disable SMB2. http://blogs.msdn.com/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx It's amazing, as we have spent countless hours Googling for this months ago, and relied on .bat files that worked 80% of the time. So far, this works 100% of the time. This is a miracle for us!!! We've worried for 6 years about this problem. - Show quoted text - ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
-Messaggio Originale- Da: francesco perillo fperi...@gmail.com A: Harbour Project Main Developer List. harbour@harbour-project.org Data invio: venerdì 30 aprile 2010 18.04 Oggetto: Re: [Harbour] SMB1 and SMB2 Enrico, do a search on past messages. There was a person that had several serious issues with smb2. From memory, he solved applyuing a security patch that allowed to disable smb2... Thank you. 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 (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
-Messaggio Originale- Da: Lorenzo Fiorini lorenzo.fior...@gmail.com A: Harbour Project Main Developer List. harbour@harbour-project.org Data invio: venerdì 30 aprile 2010 18.14 Oggetto: Re: [Harbour] SMB1 and SMB2 I've found some msgs about it. In my gmail the first reference is: Thank you. 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 (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
-Messaggio Originale- Da: francesco perillo fperi...@gmail.com A: Harbour Project Main Developer List. harbour@harbour-project.org Data invio: venerdì 30 aprile 2010 18.31 Oggetto: Re: [Harbour] SMB1 and SMB2 From a thread started by smu johnson on March 3 Thank you. 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 (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
Hi Francesco, Can you test following Harbour call, to see how well it works? ? WIN_OSNETREGOK( .T., .T. ) (you need to be logged in as administrator to make the above call successful) Viktor On 2010 Apr 30, at 18:31, francesco perillo wrote: From a thread started by smu johnson on March 3 Well we have a ton of people who still use Windows, and because of that we need a Windows solution. I am happy to report that after about 30 mins of Googling, I came across this page, which solved the problem, if you disable SMB2. http://blogs.msdn.com/robmar/archive/2009/09/23/get-microsoft-fix-it-for-smb2-issue.aspx It's amazing, as we have spent countless hours Googling for this months ago, and relied on .bat files that worked 80% of the time. So far, this works 100% of the time. This is a miracle for us!!! We've worried for 6 years about this problem. - Show quoted text - ___ 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] SMB1 and SMB2
Enrico should answer... I just forwarded the message... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SMB1 and SMB2
-Messaggio Originale- Da: francesco perillo fperi...@gmail.com A: Harbour Project Main Developer List. harbour@harbour-project.org Data invio: venerdì 30 aprile 2010 19.09 Oggetto: Re: [Harbour] SMB1 and SMB2 Enrico should answer... I just forwarded the message... Sorry, I can't make any significative test right now. 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 (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14415] trunk/harbour
Great stuff. Thanks a lot! Viktor On 2010 Apr 30, at 11:39, dru...@users.sourceforge.net wrote: Revision: 14415 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14415view=rev Author: druzus Date: 2010-04-30 09:39:25 + (Fri, 30 Apr 2010) Log Message: --- 2010-04-30 11:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbznet.c ! fixed stupid typo which caused that hb_znetFlush() in encrypted buffers never returned 0 (the returned value was increased by 4) * harbour/contrib/hbnetio/netio.h * harbour/contrib/hbnetio/netiocli.c * harbour/contrib/hbnetio/netiosrv.c * harbour/contrib/hbnetio/readme.txt + added support for communication streams/channels which allow to send asynchronously data from server to client. The following client side functions had been added: NETIO_OPENDATASTREAM( cStreamFuncName [, params,...] ) - nStreamID NETIO_OPENITEMSTREAM( cStreamFuncName [, params,...] ) - nStreamID NETIO_CLOSESTREAM( nStreamID, [cServer], [nPort] ) - lOK NETIO_GETDATA( nStreamID, [cServer], [nPort] ) - aData | cData | NIL The following server side functions had been added: NETIO_SRVSTATUS( pConnectionSocket [, nStreamID] ) - nStatus NETIO_SRVSENDITEM( pConnectionSocket, nStreamID, xData ) - lSent NETIO_SRVSENDDATA( pConnectionSocket, nStreamID, cData ) - lSent + added RT errors to the netio client code. They should help to early detect any communication problems ! disabled hb_socketSetNoDelay() in client and server code. I enabled it for some local tests and by mistake committed to SVN and I didn't noticed it. It could cause serious problems in some cases i.e. with slow WiFi or WAN connections. Warning: server signature changed due to extensions in protocol. both client and server side has to be updated and use current SVN code. + harbour/contrib/hbnetio/tests/netiot03.prg + added demonstration/test code for alternative RDD IO API, RPC and asynchronous data streams in HBNETIO Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbnetio/netio.h trunk/harbour/contrib/hbnetio/netiocli.c trunk/harbour/contrib/hbnetio/netiosrv.c trunk/harbour/contrib/hbnetio/readme.txt trunk/harbour/src/rtl/hbznet.c Added Paths: --- trunk/harbour/contrib/hbnetio/tests/netiot03.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] SMB1 and SMB2
Yeah, this SMBv2 patch fixed everything for us. It became a problem when SMB2 was running for doing .dbf file access over a simple run-of-the-mill Windows Shared Network. We could have used HBNETIO, but we didn't want to have to change hundreds of lines of code where the NET USE code would end up going. Anyways, please let me know if the smbv2 disable patch works for you. If you are doing what we are doing, which is filesharing, only the host of who is sharing the files needs the patch installed. ___ 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:[14415] trunk/harbour
Awesome !!! Thank you ___ 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:[14415] trunk/harbour
druzus wrote: Revision: 14415 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14415view=rev Author: druzus Date: 2010-04-30 09:39:25 + (Fri, 30 Apr 2010) Log Message: --- 2010-04-30 11:39 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/src/rtl/hbznet.c ! fixed stupid typo which caused that hb_znetFlush() in encrypted buffers never returned 0 (the returned value was increased by 4) * harbour/contrib/hbnetio/netio.h * harbour/contrib/hbnetio/netiocli.c * harbour/contrib/hbnetio/netiosrv.c * harbour/contrib/hbnetio/readme.txt + added support for communication streams/channels which allow to send asynchronously data from server to client. The following client side functions had been added: NETIO_OPENDATASTREAM( cStreamFuncName [, params,...] ) - nStreamID NETIO_OPENITEMSTREAM( cStreamFuncName [, params,...] ) - nStreamID NETIO_CLOSESTREAM( nStreamID, [cServer], [nPort] ) - lOK NETIO_GETDATA( nStreamID, [cServer], [nPort] ) - aData | cData | NIL The following server side functions had been added: NETIO_SRVSTATUS( pConnectionSocket [, nStreamID] ) - nStatus NETIO_SRVSENDITEM( pConnectionSocket, nStreamID, xData ) - lSent NETIO_SRVSENDDATA( pConnectionSocket, nStreamID, cData ) - lSent + added RT errors to the netio client code. They should help to early detect any communication problems ! disabled hb_socketSetNoDelay() in client and server code. I enabled it for some local tests and by mistake committed to SVN and I didn't noticed it. It could cause serious problems in some cases i.e. with slow WiFi or WAN connections. Warning: server signature changed due to extensions in protocol. both client and server side has to be updated and use current SVN code. + harbour/contrib/hbnetio/tests/netiot03.prg + added demonstration/test code for alternative RDD IO API, RPC and asynchronous data streams in HBNETIO Something extraordinary. Harbour community will ever remain indebted to your contributions. I have already started base work how effectively I can port my applications to reside on server for their better part. Thank you for such excellency. - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://harbour-devel.1590103.n2.nabble.com/SF-net-SVN-harbour-project-14415-trunk-harbour-tp4984712p4987729.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] SF.net SVN: harbour-project:[14415] trunk/harbour
Przemek must know a lot about computers and Harbour! On Fri, Apr 30, 2010 at 2:39 AM, dru...@users.sourceforge.net wrote: Revision: 14415 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=14415view=rev Author: druzus Date: 2010-04-30 09:39:25 + (Fri, 30 Apr 2010) ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Hi Viktor, It turns out that my tests of doing the devout calls to the screen in Win9x with the unicows solution is about 2 or 3 times slower than non-unicode compiled .EXEs on the same machine. And this is with Przemek's SET CURSOR OFF trick as well for Win9x machines... So this simple test and its performance hit would leave me to conclude that the unicows solution isn't 100% perfect. Just my two cents. If it cannot be solved, then I suppose my vote would be to still keep the non-unicode mode...? I don't know enough about Harbour to see the implications :[ On Thu, Apr 29, 2010 at 5:13 AM, Viktor Szakáts harbour...@syenar.huwrote: It's unlikely we shall ever support Windows 3.x or Win32s, and unicows solution works just perfect now to cover Win9x/ME host versions, ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Removal of non-UNICODE Windows codepath?
Update: well I did a raw DEVOUT for loop test, and it was a only about 10% slower. The 2 or 3 times slower claim was in the ap we use itself, where we have another test which does almost the same thing, and it is about 2 or 3 times slower... not sure what really is responsible, only thing I know of that changed on my end was the non-unicode / unicode build... *confused* On Fri, Apr 30, 2010 at 2:01 PM, smu johnson smujohn...@gmail.com wrote: It turns out that my tests of doing the devout calls to the screen in Win9x with the unicows solution is about 2 or 3 times slower than non-unicode compiled .EXEs on the same machine. And this is with Przemek's SET CURSOR OFF trick as well for Win9x machines... -- smu johnson smujohn...@gmail.com ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
