I made a discovery regarding this nagging error that has been
reported occasionally during Indexing operations.
We found this out because we made a subtle change to our app's
statusbar display of today's date. All we did is make a call to
__SetCentury(.t.), and the ADS 6619 error started occu
Ron:
I'm very sorry I lost the ability to duplicate this.
I was doing some data fixups in our office with an .xbs file
(with a Main func and one other function at the bottom),
then made a change to the Main code and out of the blue
it threw an error "compiling" the function at the bottom--
a func
rth the trouble, and unlikely to
be supported in other RDDs anyway?
--
Brian Hays
> -Original Message-
> From: Przemysław Czerpak [mailto:dru...@acn.waw.pl]
> Sent: Tuesday, December 01, 2009 3:15 PM
> To: bhays; 'Viktor Szakáts'; Harbour Project Main Developer List.
I need help with a decision on whether to throw an error or not. Please see
discussion below.
2009-12-01 01:37 UTC-0800 Brian Hays
* contrib\rdd_ads\ads1.c
+ Added support for ordDescend's 3rd arg to dynamically change
the index direction between ascending / descending.
O
Przemek and Mindaugas:
Thanks for the clarification. I missed the finer point when Mindaugas
first discussed "ADS", but then the second paragraph said
"I propose to rename RDD from ADT ..."
as you noticed, I thought we were still talking about just "ADS".
So, yes, I would agree ADSADT is better
Mindaugas:
If you intended it for the Harbour project, please keep this xHarbour group
and/or me in the conversation. I have continued to work with Viktor
and Przemek to keep rddads coordinated as much as possible in both projects.
It may be worthwhile to forward my concerns to the other project
Mindaugas:
I'm not sure why you're making the suggestion.
Right now, the original "ADS" is an all-inclusive rdd that lets
you switch the file type to cdx, ntx, etc. in different workareas.
The addition of specific "sub-rdds" of ADSCDX etc. came years later.
I, and I imagine a lot of other people
Ron:
I believe Uncompress has the same bug that was fixed in hb_compress a
few months ago, where the string it returns is using hb_retclenAdopt()
instead of :
hb_retclenAdoptRaw( cDest, ulDstlen );
which leaves the HB_ITEM malformed. Though that bug only revealed itself
in failed macro
2009-07-16 19:30 UTC-0800 Brian Hays
* contrib\rdd_ads\ads1.c
* fixed buffer handling for adsScopeSet and GetValue and related funcs.
Since way back, buffers were short by 1 byte, and ace calls were
throwing errors that were essentially ignored. It only worked because
the
table
for years, and we can't know for sure what might happen for data that
contains
nulls, or if ADS guarantees there's always a NULL that can be omitted.
Thanks,
--
Brian Hays
Abacus Data Systems, Inc.
From: bhays [mailto:bh...@abacuslaw.com]
Sent: Saturday, July 11, 200
Miguel:
I'm trying to look over the changes to ads1.c to help with the character
field length problem.
There are a few changes I don't understand.
Why was the explicit NUMERIC test
else if( hb_itemType( pKey ) & HB_IT_NUMERIC )
changed to
else if( HB_IS_NUMERIC( pKey ) )
?
Is
ptRaw
vs.
hb_retclenAdopt
??
Thanks!
--
Brian Hays
Abacus Data Systems, Inc.
From: Ron Pinkas [mailto:ron.pin...@xharbour.com]
Sent: Friday, July 10, 2009 8:22 AM
To: bhays; 'xharbour developer list'
Subject: Re: [xHarbour-developers] hb_uncompress in hbc
Miguel:
RDDADS has had its own flavor of timestamps for a long time.
Do you expect this new change to work with that, or is it
a different system that still needs to be integrated?
Thanks,
--
Brian Hays
> -Original Message-
> From: Miguel Angel Marchuet [mailto:miguelan...@marchuet.ne
FYI, Sybase/iAnywhere/Extended Systems/Advantage has officially announced
their new NG:
xHarbour Newsgroup
Due to requests and demand the Advantage Database Server team has started an
xHarbour newsgroup! Information for connecting the newsgroup can be found on
the Advantage Developer Zone.
http://
Ron:
The difference is: We have always built with this function available,
and there is NO discernable overhead.
Building with debug info DOES have discernable overhead.
So if people use this call, they will have a surprise after shipping with
the new build and eventually trying to use it and havi
Miguel and Ron:
> Ye has little overhead, but by default terminal aplications don't need it.
> TRACE is a good tool for developers, but not for released.
I respectfully but strongly disagree.
First of all to clarify the bigger picture for Miguel:
Thank you so much for all the great work you'v
I met with our Sybase/iAnywhere/AdvantageDatabase reps today, and they
mentioned they were seriously looking at adding an xHarbour newsgroup if a
few people would commit to monitoring it.
I said I would be happy to be involved.
If anyone else wants to volunteer, tell me and I'll forward your na
--
> From: Francesco Saverio Giudice [mailto:i...@fsgiudice.com]
> Sent: Saturday, January 17, 2009 3:30 PM
> To: 'xharbour developer list'
> Subject: Re: [xHarbour-developers] 2009-01-17 16:55 UTC+0100 Francesco
> Saverio Giudice (info/at/fsgiudice.com)
>
> Hi B
Francesco:
Would it make sense to have this feed into the existing hblog
functionality, which has all the features to go email, file,
inet ports, etc.?
--
Brian Hays
Abacus Data Systems, Inc.
> -Original Message-
> From: Francesco Saverio Giudice [mailto:i...@fsgiudice.com]
> Sent: Satu
Miguel:
It sounds like you're saying that if you build cvs with
HB_NO_PROFILER (the default), and then try to call any of
the profiler functions, you get a gpf.
If so, this isn't OK to ship. We've always supported transparent
calls (no error, just no results) to the profiler funcs when its
piec
Are we going to change the pcode version for this release?
I believe I only saw Yes votes on that topic. Who can do it?
--
Brian Hays
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge want
Patrick:
I think the point is that there's nothing special about FWH;
any other 3rd party lib will need its PRGs compiled, right?
(let me know if I'm wrong)
In which case forcing this up front, as much as it creates headaches,
is far better than finding out at app runtime.
--
Brian Hays
>
Patrick:
I understand. But if we're going to release a build that causes
unidentifiable crashing, shouldn't we consider putting something in the
build to identify it?
Wouldn't incrementing the PCode version accomplish this, even if it was an
item structure change instead of pcode change that caus
.it]
> Sent: Tuesday, January 06, 2009 2:07 PM
> To: bhays; 'xHarbour-Developers'
> Subject: Re: [xHarbour-developers] Current CVS stable?
>
>
> -----Messaggio Originale-
> Da: "bhays"
> A: "'xHarbour-Developers'"
> Data invio:
With the current cvs, our ErrorSys in Fivewin apps is throwing a gpf.
We're debugging now and will let you know as soon as we identify
what's different between this and earlier builds.
--
Brian Hays
Abacus Data Systems, Inc.
> -Original Message-
> From: Patrick Mast [mailto:patrick.m...@
gain
AFAIK ever since (March of 2007), FWH has been clean.
So can someone point me to where in FWH there continue to be any problems?
Thanks,
--
Brian Hays
> -Original Message-
> From: Miguel Angel Marchuet [mailto:[EMAIL PROTECTED]
> Sent: Sunday, November 30, 2008 2:36
Sorry to chime in so late on this, but I don't think
HB_LEGACY_LEVEL
is good terminology.
Two years from now what we do today
will be Legacy, and the reference becomes ambiguous.
Is there any reason it cannot instead refer to the last PCODE
version that was parallel to the change in item structu
Patrick:
The hooks must be "mostly" done since the "trigger" is the equivalent of
setting a tracepoint in the debugger, but with a user-defined action.
--
Brian Hays
From: Patrick Mast, xHarbour.com [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2008 2:24 AM
To: xHarbour-Developers
Su
I hadn't used the debugger with a Fivewin app in a while. It had been
working
some over the previous year or so.
Now, the console window stays black, ; no UI paints, and it just hangs on
altd().
If I don't call altd() anywhere the app does run, but the debugger console
never
shows anything.
Miguel:
Thanks!
There's one change I don't quite understand.
Could you give me a better idea of what this means:
! fixed to not respect bitmap filters when structural order
is scanned, f.e. in OrdListAdd() with active bitmap filter.
does "scanned" mean searching thru the database? When
Has anyone fully tested InetRecvAll() ?
We have an unresolved problem with the Internet communication functions.
We've been unable to reduce it to a small sample, so I don't expect this to
stop finalizing a release. But it would be good to know if a lot of people
have
done a lot of testing of th
>> Do we need to fix ours like Przemek proposes?
It sounds correct to me.
--
Brian Hays
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Patrick Mast, xHarbour.com
> Sent: Friday, July 25, 2008 6:34 AM
> To: xHarbour-Developers
> Subject: [xHarbo
Ron:
Using the cvs from June 4, my app performed wonderfully (the best ever)
under our stress test, although manual testing with some windows did have
those
errors Luis was discussing.
The new cvs after your fixes does indeed seem to fix those errors, but
now the stress test is failing.
users shouldn't have to tell it NOT to do something unexpected.
--
Brian Hays
> -Original Message-
> From: Enrico Maria Giordano [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 13, 2008 2:40 PM
> To: bhays; 'xHarbour-Developers'
> Subject: Re: [xHar
Ron:
MAKE_B32 CLEAN
will continue to rebuild ALL.
If your intention is to clean existing files but just do a
core build, it's pretty awkward.
Did we arrive at a consensus to have that command just CLEAN
files, and require a second command to rebuild?
I believe I've seen 3 informal votes to ch
l Message-
> From: Ron Pinkas [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 05, 2008 5:30 PM
> To: Ron Pinkas
> Cc: bhays; 'xHarbour-Developers'
> Subject: Re: [xHarbour-developers] PREMATURE ARRAY/OBJECT RELEASE
> DETECTED O 16BA914
>
> Brian,
>
> Jus
specific
boundary conditions.
--
Brian Hays
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Ron Pinkas
> Sent: Thursday, June 05, 2008 4:46 PM
> To: bhays
> Cc: 'xHarbour-Developers'
> Subject: Re: [xHarbour-developers] PR
This is a CRITICAL error.
Users of my full Fivewin app are getting this Unrecoverable error
when closing an MDI child window.
This is when the garbage collector gets invoked (there are dialogs
on my MDI windows, and FWH calls hb_gcAll() upon closing a dialog).
There are other MDI child windows o
The recent post had a ton of little changes that may hide a few new features
that people had been asking for. The following should be in any whatsnew
docs. Some of these are new funcs, some are restored that got
accidentally removed sometime in the past year, and some are minor
enhancements.
I was expecting to build just the core and rddads, but first I wanted
to make sure it was a CLEAN build so I ran
MAKE_B32 CLEAN
After deleting appropriate files, this then jumps into compiling EVERYTHING.
Is this really the syntax we want? Shouldn't Clean only do that?
Otherwise, how a
dnesday, June 04, 2008 1:14 AM
> To: bhays; 'xHarbour-Developers'
> Subject: Re: [xHarbour-developers] Errors in latest CVS
>
>
> -Messaggio Originale-
> Da: "bhays" <[EMAIL PROTECTED]>
> A: "'Enrico Maria Giordano'" <
Enrico:
How exactly did you try to build it? With the new supplied batch file?
Did you set (and were you prompted to set) the new envvars?
--
Brian Hays
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Enrico Maria Giordano
> Sent: Wednesday, J
> In summary, my effort was to help minimizing missmatch issue among
> ace32.lib and ace32.dll. If it proved that it only creates a hassle
> then I'm sorry. We could dettached it from the makefile and remove the
file.
Andi:
No need to apologize; it's a great idea. We just have to figure out
if it
Andi:
When I discussed this issue with Ron, he was of the opinion that
this module could be auto-generated from the DLL itself, thus
eliminating the maintenance issues in pursuing things like this.
Can you see if that's possible, and if it can solve these details?
I'm concerned that we should n
Andi (And ADS Linux users):
In your new ace32.c "GetProcAddress" approach, there's a MessageBox call:
char __szError[256];
sprintf( __szError, "Cannot find function address: %s", szFuncName
);
MessageBox( NULL, __szError, szFuncName, MB_ICONSTOP );
re
Miguel and other RDD developers:
Apparently the gpf problem we're having in sharing rddads with the
Harbour project is because of the C Struct changes.
It's my understanding that all RDD WA structures need to match up to
a certain point, and then specific rdds can add properties afterwards.
gt; From: Miguel Angel Marchuet [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 23, 2008 12:49 AM
> To: bhays
> Cc: 'xHarbour-Developers'
> Subject: Re: [xHarbour-developers] RDD compatibility
>
>
> >
> > xhb hb
> >
&g
Every time ADS comes out with a new version-and sometimes even a minor
version-
there are changes to ace.h.If we make changes to an ace.h that we
distribute, we
continue the mindless cycle where someone happily uploads the new ace.h,
and some "needed" changes are lost, and someone has to hac
Andi and all:
I have spent many hours over the past week trying to deal
with all the new features done to rddads in Harbour.
Since what I've been talking about is a whole replacement
of the source files, any posts you do now would have to
be re-synced with the new files.
Are you prepared to re-do
Andi:
With Viktor's new system, these issues would all go away because
the build would look to the correct acesdk folder for the right
header, and we would REMOVE ace.h from our cvs completely.
It does however put the responsibility on the user to have the
acesdk folder set up correctly for the d
Correction on the func table, I had missed a CVS error was looking at the
wrong code.
We added a fourth arg that Harbour doesnt have, so DBENTRYP_RVVL
should be the right and simple fix, right?
So the main issue now is the field types
--
Brian Hays
Subject: [xHarbour-developers] RDD compatibi
Miguel and friends:
I'm not sure of the state of compatibility between Harbour and xHarbour
RDDs.
The Harbour RDDADS code has some problems with our current cvs that I'm
hoping you can educate me on.
In ads1.c, it changed some of the field type constants and renamed the
following #defin
Ron:
> I was just annoyed
> at the lack of interest in preserving compatibility. This is not the
> first and probably not the last time we have to deal with name
> changes in Harbour sources, for no reason at all.
I had the same first reaction, that preserving compatibility should
have more impor
d by the old name, but at this stage trying
to change it back would probably mean the two projects keeping
different source code.
--
Brian Hays
Abacus Data Systems, Inc.
> -Original Message-
> From: Ron Pinkas [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 20, 2008 10:30 AM
>
ADS adds functions and features on incremental releases, so the
major-version-only usage of ADS_REQUIRE_VERSION was problematic
in accurately isolating code to match libs and dlls.
In the Harbour project, Viktor created a new more accurate
ADS_LIB_VERSION to handle 3 or more digits of version#s
Toninho:
> Brian, ...I agree with Ron, but I have one doubt about:
> >ADS_REQUIRE_VERSION issue; Viktor has replaced it with a better
> >#define as part of his "auto-detecting" ...
> I, for example: have ADS 9.0 installed in my machine for tests
> pourposes, but I always compile RDDADS with ADS_R
I know people hate it when I write long msgs, but this is very
important so please everyone wade through it to find the pieces
that apply to you. I can also use some guidance on handling
cvs and the changelog. When pulling whole files over, should
I attempt to gather the myriad changelogs from th
Viktor asked me the following question about this function
in adsfunc.c, which seems to receive a 3rd arg for a Connection
handle, but then it never uses it.
Does anyone know the intention of that code?
>>
In ADSSTMTSETTABLEPASSWORD() there is a check for hConnect != 0, but later
on hConn
I am in the middle of reviewing Viktor's changes to rddads.
He made extensive changes (I think they're all good), but he chose to
reformat code throughout the file, making a file compare difficult, and hard
to see where he did "real" changes as opposed to just formatting ones, so it
is taking a wh
Patrick:
Thanks, I'll review the ads stuff; it sounds very useful.
--
Brian Hays
Abacus Data Systems, Inc.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Patrick Mast, xHarbour.com
> Sent: Wednesday, May 07, 2008 4:03 AM
> To: xHarbour-Develope
I just got confirmation from reinaldo that he was not subscribed to the list
and has not seen all the nice welcome messages.
--
Brian Hays
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss
Patrick:
> What can I tell him?
I think you should say "You're Welcome".
He should be aware of the concept of "Bug compatibility", and
how it makes no sense for us to perpetuate bad things from clipper
if fixing them doesn't create any hardship.
In this case, removing one bad line of code doesn
Here's Reinaldo's ID:
reinaldo
--
Brian Hays
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://a
Reinaldo Crespo-Bazán has been giving me code for enhancing
rddads off and on for a while now.
I think we should give him full developer status so he can post his
changes directly to the cvs. I can review from there, and work with
him on the enhancements we want to do to support the newes
Miguel:
How long have you been having the memory issues with your app?
I have not yet tested a build with recent cvs (last time was
cvs from last October), but over the last several
years we have watched this issue and have NOT had any memory
leaks that were not fixed here on this list.
We have a
Ron:
Our OutLook Add-in (OLE automation server, instantiated by that
VB plugin stub dll, using commercial xHB from a couple months ago)
has had occasional random gpfs or hanging
on some machines since we released it last October.
One user has constant problems, 99% have no problems other
than th
The fix done here is in having a C return statement after throwing the
error.
There are many places in adsfunc.c where this is not done; lots have a
"prg-level" hb_retni(0) style return, which pushes a return value but
doesn't stop execution. Presumably those are not blowing up
because they
Ron ( or anybody else with vm experience ):
This is a strange error report. Can you tell us what it means when
it says " hb_vmRequestQuery() is set" ?
Does "Couldn't create error ADSISEMPTY '(null)'" imply that the
errorsys had a problem with a badly formed error object?
I'd like to know how t
68 matches
Mail list logo
