Delphi converter in Lazarus trunk now supports also replacement of function calls. It is all configurable and user changes to the configuration are persistent. The converter settings window has a button "Function Replacements" for it. The syntax is:

ShellExecute --> OpenURL($3)

which means a call to ShellExecute is replaced with OpenURL and the third parameter from the original call is used for the new call. In this case the other params are ignored but there can be any number of comma separated params defined.

I have only a few (6) default replacements defined now. There are some file funcs like:
CreateFile --> FileCreate($1)
where the params may not match. There will be a ToDo: comment inserted after the replacement about the parameter types.

Then there is
FileExists --> FileExistsUTF8($1)

The idea is to add all file name related functions that have a ...UTF8 counterpart, and make their replacement optional somehow.

Now I would need more function names and parameters to replace. Other comments are welcome, too.

Juha

Hans-Peter Diettrich wrote

I just wonder why special UTF8 functions are the current RTL cannot handle unicode file names, so we need a

different unicode routine.

overloaded procedures should be sufficient if ever required.

Impossible, because they are implemented in different packages and because you can't differentiate from utf-8 and ansi string at the moment.

I just wonder why special UTF8 functions are the
user VP the use of UTF-8 arguments should not deserve different procedures, overloaded procedures should be sufficient if ever required. But this most probably is an FPC topic, about the distinction and possibly automatic conversion between Ansi/MBCS, UTF-8 and UTF-16/Wide strings.

If the type AnsiString had not been defined and used improperly in Delphi, we could default String to ASCII or UTF-8 encoding, and have more AnsiString or SBCS/MBCS string types with an explicit Encoding tag included. AFAIK in Delphi it just turned out that the new AnsiString is incompatible with older DLLs, due to the added Encoding tag. While such a tag should be restricted to the Delphi RawByteString, the name is an horrible misnomer - a RAW BYTE string IMO should have no encoding at all, with no automatic conversion, also usable for e.g. binary data or other locale-invariant content (lookup of nationalized text...). Instead an EncodedString type could have an Encoding tag, so that eventually required conversions etc. can be determined by the RTS.

DoDi

Hans-Peter Diettrich schrieb: I just wonder why special UTF8 functions are the user VP the use of UTF-8 arguments should not deserve different procedures, overloaded procedures should be sufficient if ever required.

I don't think so. It just opens a can of worms. The user will believe that there is no need to pay attention to encoding, the compiler will do it all for him. But that's not true. Even if it works in some circumstances, it's not a solution for all cases. The user should be kept aware that he is working with different encodings. It can also happen, that different encoding types are handled by a program. If the user can not rely on getting back a certain encoding it will be a severe problem. It may be not so convenient to use different function/procedure names but it keeps everything it also makes clear where conversions (with possible loss of characters) are needed/appear.

This care only applies to non-Unicode strings, that's why I suggested an Encoding flag for just these files. Conversion into UTF-8 or Widestring is lossless, any other conversion should require an explicit encoding.

DoDi

shellexecute isn't only used for urls. Do you chekc if the third argument starts with http:// or so?

Yes, ShellExecute can be mapped to OpenURL, OpenDocument or even a program execution routine. In some cases it can be used even to print o.O

Felipe Monteiro de Carvalho wrote

Yes, ShellExecute can be mapped to OpenURL, OpenDocument or even a program execution routine. In some cases it can be used even to print o.O

In general it is mostly "execute based on program extension, except when protocol (mailto:/,http:// etc) is prefixed.

Marco van de Voort wrote

In general it is mostly "execute based on program extension, except when protocol (mailto:/,http:// etc) is prefixed.

Then it should be mapped to OpenDocument() and sometimes to OpenURL

Felipe Monteiro de Carvalho wrote

> In general it is mostly "execute based on program extension, except when > protocol (mailto:/,http:// etc) is prefixed. Then it should be mapped to OpenDocument() and sometimes to OpenURL

And if it is not 100% clear, it should be left alone.

Nothing the converter does is 100% clear.

Maybe the converter can add comments, what it has done.

Mattias

kinda what i was thinking, too... from the name of the function, it would seem that this is a common way of executing any external apps or commands...

Mattias Gaertner wrote

Nothing the converter does is 100% clear. Maybe the converter can add comments, what it has done.

+1

shellexecute isn't only used for urls. Do you chekc if the third argument starts with http:// or so?

I could extend the syntax to do that. I will also add the comments later.

Fully automatic conversion is not realistic. The person has to go through the code manually anyway, so 100% accuracy is not required here.

Juha

Probably you already do this: if the project uses the LCL it should use the unit FileUtil.

Mattias

Then there is FileExists --> FileExistsUTF8($1)

Now only I realized that FileExistsUTF8 and other "UTF8" functions are defined in codetools FileProcs unit.
I guess a dependency for it should be added to the converted projects. At least there is no dependency for LCL so it could be used for console applications, too.

Juha

Uses section?
Maybe you mean required package?
BTW, unit FileUtil is one of the base units of the LCL, without widgetset dependencies. Using it in console applications is safe.

Note: Eventually such units will be put into a separate package. But I don't want to make many people's live harder just to make things more clean for a few experts. When we switched to fpmake and improved a few things in the IDE the time will come.

I guess it is again some more duplicated code between codetools and LCL.

Also keep in mind that codetools units are under GPL.

The problem comes when converting console applications. The easy solution will be not to convert those UTF8 functions for console apps. It is not very logical though because file name conversions should not depend on the GUI library LCL.

If you want to convert it to a LCL application, you probably want to use UTF8 file names.
But when converting a console application it is not clear if UTF8 filenames is a good choice (IMO).

Mattias

Probably you already do this: if the project uses the LCL it should use the unit FileUtil.

Ok, it is either codetools/FileProcs or lcl/FileUtil, depending on which one is last in Uses section.

I guess it is again some more duplicated code between codetools and LCL.

The problem comes when converting console applications. The easy solution will be not to convert those UTF8 functions for console apps. It is not very logical though because file name conversions should not depend on the GUI library LCL.

Juha

Mattias Gaertner wrote

Maybe the converter can add comments, what it has done.

It does now. The comment is added at the end of the converted function which makes the line long sometimes. I can later try adding a new line for the comment in front of the function call.

I try to make the replacement function configurable based on a parameter value, too.

Juha

It is GUI related.
The lazarus GUI uses UTF-8, so when transferring a filename from a TFileNameEdit (or TOPenDialog) to a FileOpen() function, the conversion from UTF-8 to system encoding must be done.

Console applications will normally not use UTF-8 in the first place, they will normally be using system encoding from the start, so it is a bad idea to insert conversion routines, since none is necessary to start with...

Michael.

Mattias Gaertner wrote

Uses section? Maybe you mean required package?

Maybe. I have lazarus.lpi open and my mind is mixed up.

BTW, unit FileUtil is one of the base units of the LCL, without widgetset dependencies. Using it in console applications is safe.

Yes, after adding LCL dependency and NoGUI widgetset. Currently the converter does not add LCL dependency for console apps. I will make it optional later. Some developers considered NoGUI widgetset as a bad idea, as you remember.

But when converting a console application it is not clear if UTF8 filenames is a good choice (IMO).

Can you please explain. I don't know the details here. I thought file name conversion is an OS related issue, not GUI related.

Juha

It is, because you see no warning if you use widgetset functions, that do not work.
But unit FileUtil and some other base units work widgetset independent. They are more like FCL extensions but in a lazarus way of doing it.

Yes, if you only target windows.
If you want to convert a delphi console program to let it run under Linux or Mac, then you have to check all file functions. If you use system encoding, widestring or utf8 depends depends heavily on the code and there is no good general advice.

Mattias

Agreed 100%.

Michael.