ppFixUpFloatString problem

rbuser

RB 14.08

My colleague has modified a report (DADE) and this has resulted in an
SQL error whenever the Query Designer editor is OK'd. The bad SQL is due
to the VALUE of a SEARCH criterion for an integer field NOT being
written to the final SQL output, so you end up with:

Jobs.JobNo IN ()

The problem can be traced to StrToFloat(Result) in ppFixUpFloatString:
an EConvertError kicks in when the Result is clearly a legal integer
string. The underlying problem is that the system DecimalSeparator at
this point has a value of #0 (!!) as if it was being assigned from a
PChar and only picking up the null terminator value. If I replace
StrToFloat(() with Val() it sorts it out, the latter not using the
global DecimalSeparator.

The odd thing is that its just design stuff in the report that seems to
be causing the problem and if a previous version of the report is loaded
it works fine, although not within the lifetime of the program if its
already gone wrong. Having said that, we have our own currency
formatting code that sets the DecimalSeparator whenever we open other
forms in our app that need currency formatting independent of actual
machine locale, and if we do that then it has the side effect
immediately fixing the problem in the Report Designer, which is what one
would expect.

Any ideas?

nicocizik

Hi Paul,

When altering the global FormatSettings (DecimalSeparator for instance)
be sure to also update the ReportBuilder specific ppFormatSettings property.

uses
ppUtils;

...

FormatSettings.DecimalSeparator := ',';
ppFormatSettings := FormatSettings;

rbuser

Hello Nico,

The Report Designer will exhibit this problem even if our code to set
DecimalSeparator has NEVER been called.

In the places where we change the DecimalSeparator in our custom
reporting code (RAP passthrus) we do indeed adjust ppFormatSettings, but
even this code has not yet fired when we get this problem as its at
designtime, not print/execute time.

rbuser

Hello again Nico

Your comment made me refactor some of my code and ensure that all writes
to global formatsettings were pushed through a manager class, and once
that was done I discovered that an uninitialized local variable in my
own custom TppDisplayFormat class is the culprit for screwing up
DecimalSeparator.

Apologies if I set you on a wild goose chase, but you did help me focus
my mind somewhat.

Thanks again, Paul