From PropEditUtils.pas (recently split by me from PropEditS.pp):

TGetStringProc = procedure(const s:ansistring) of object;

From Classes.pp:

TGetStrProc = procedure(const S: string) of object;

I think TGetStringProc is redundant and should be removed. Should I prepare a patch?

Zitat von Alexander Klenin :

> From PropEditUtils.pas (recently split by me from PropEditS.pp):

Every change to the IDEIntf must be documented here: http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_release_notes

No. I removed it in 23499.

Mattias

2010/1/20 Mattias G?rtner :

Done.
However, there are more then 60 changes in ideintf made in December and January only,
and none of them is documented in release notes AFAICS.

> I think TGetStringProc is redundant and should be removed. > Should I prepare a patch? No. I removed it in 23499.

Thanks for the quick response, but I had a more comprehensive change in mind -- remove TGetStringProc altogether and replace all the references with TGetStrProc.
So, should I prepare that patch?

Zitat von Alexander Klenin :

Some additions were documented elsewhere with complete examples. But any incompatibility should be documented on the release note.

Yes. But keep the alias for compatibility.

Mattias

i notice that one is "string" and the other is "ansistring"... aren't they different enough to possibly cause problems where one is expected by the use of the old routine and suddenly the new one doesn't support the same?

No, both are ansistring.

Mattias

ok... thanks for that... i was unaware that type "string" was an alias for "ansistring"... i had thought that "string" was the same as the old borland "string" definition (ie: array of chars with the [0] element containing the string length) ;)

ok... thanks for that... i was unaware that type "string" was an alias for "ansistring"... i had thought that "string" was the same as the old borland "string" definition (ie: array of chars with the [0] element containing the string length) ;)

In newer Delphi versions (2009+) "string" is "UnicodeString", that's why using "AnsiString" will reduce possible confusion of people, who use Delphi and Lazarus concurrently.

string[n] is "ShortString", even in the new Delphi versions.

DoDi

string is ansistring in lazarus sources since 10 years. I guess, most lazarus users are used to it.

Mattias

thanks for that... this is some of the basic changes that i have to try to remember as i attempt to move from TP/BP 6/7... i can already see that many of my own libs will need major overhauls since they operate at a lower level than the basic included libs... heck, my most used lib does direct screen writes to any screen format buffer but that's all out the window when it comes to GUI apps stuffs :?

i understand but i (among others) am a new lazarus user trying to become familiar with no real and easily read and understood documentation or books... yes, everyone says to use a basic delphi book but even that runs into problems when routines are different names or replaced by something else... i won't even mention things like "use this widget from this panel" and the widget and/or panel don't exist or are named differently... believe me, i've tried and i cannot count the number of books i've returned because they were useless to me when trying to learn laz/fpc :?