Hello,
are StrUtils just for Delphi compatibility or are they meant for "real use"? In the first case, is there an alternative unit? In the second, would simple patches to implement "AnsiStartsStr" and "AnsiEndsStr" with CompareMem (for starters) be accepted?

Best regards,
Flávio

They would be accepted.

Michael.

If accompanied by tests :)

Jonas

I have a program that rune continuously. Now we have had a shift from winter to summer time. I could not get my program to adopt the right time before I stopped and restarted the program.
Is there a function I can call (every hour shift) so I am sure that my program always gets the right local time

Carsten

I've exact the same Problem.
It seems that the daylight saving offset is only calculated once on program start.
Is there a method to update that ?

Alex

Alexander Bauer wrote

I've exact the same Problem. It seems that the daylight saving offset is only calculated once on program start. Is there a method to update that ?

No. The InitLocalTime procedure is private to the implementation of the unix unit. We can make it public, please post a bugreport for this.

Michael.

No. The InitLocalTime procedure is private to the implementation of the unix unit. We can make it public, please post a bugreport for this.

Do you know if it would be nessery to call DoneLocalTime before caling InitLocalTime.

Carsten
Med venlig hilsen
Carsten Bager

BEAS A/S
Brørupvænget 10
DK-7650 Bøvlingbjerg
Tlf. : +45 9788 5222 Fax : +45 9788 5434
www.beas.dk

As far as I can see not; the routines use reallocmem.

Michael.

2010/3/29 Jonas Maebe :

First question: is there a rule for test project names? Is tstrutils1.pp ok? Do I have to register the file somewhere? (couldn't find anything about it on the wiki)

Second question: In current code, when ASubText is '', AnsiStartStr returns False and
AnsiEndsStr returns True. Is this correct?

Best regards,
Flávio

GetLocalTimezone(fptime);

This method is pulic and is enough to calculate the new daylight saving offset.
Thanks for the hint.

Alex

The name doesn't matter, since renaming a file is easy (it will be renamed by us to "tw<mantis bug nr>.pp"). The only requirement for the test is that it is a plain console app that returns a 0 exit code if successful, and a non-zero exit code if it fails.

Second question: In current code, when ASubText is '', AnsiStartStr returns False and AnsiEndsStr returns True. Is this correct?

I don't know.

Jonas

In our previous episode, Fl?vio Etrusco said:

Second question: In current code, when ASubText is '', AnsiStartStr returns False and AnsiEndsStr returns True. Is this correct?

If the string='' then ansistartsstr returns true and endstr false

if they string'' then both return false.

I'm using the Dutch locale in windows 7.

Warning: one of the reasons I never bothered with the ansi* routines is:
- they are supposed to be locale dependant in their comparisons.
- they have support for mbcs versions of eastern locale codepages, where chars are not one byte.

For these reasons, I left them high and dry till we have a bit more direction on unicode. (which might skip them all together)

I don't quite follow. This is what I get:

AnsiStartsStr('', '') = FALSE
AnsiStartsStr('', 'aaa') = FALSE
AnsiEndsStr('', '') = TRUE
AnsiEndsStr('', 'ab') = TRUE

Should I retain this behavior or what?

Sure. I know this would be relevant for sorting, but are there a locale were different byte sequences should be considered equal? Actually I guess that there are (like ae vs æ?), but anyway using CompareMem is better than the current implementation.

For these reasons, I left them high and dry till we have a bit more direction on unicode. (which might skip them all together)

I imagined that.

Best regards,
Flávio

Issue tracker:
http://bugs.freepascal.org/view.php?id=16153

2010/3/30 Flávio Etrusco :