I have some shared code which has conditionals built in to check the Delphi version. When I use these functions in Lazarus 1.6/Fpc 3.0 on Windows7 I get a compile error as follows:

FormClient.pas(152,7) Error: Incompatible types: got "AnsiString"
expected "Int64"
FormClient.pas(152,7) Error: Compile time expression: Wanted Boolean
but got <erroneous type> at IF or ELSEIF

The offending code looks like this:

  {$IF CompilerVersion >= 20} {Delphi 2009 = 20..}
	  with TMemIniFile.Create(IFile, TEncoding.UTF8) do
  {$ELSE}
	  with TMemIniFile.Create(IFile) do
  {$IFEND}

What should i do to make this error go away?

I do not understand from where it gets the error message about int64 and AnsdiString...

Second question:
----------------
I use a TFolderDialog component in the program to select a target directory. Apparently this component is not native Delphi (although I have used it for years) and so Lazarus barfs at it... Is there a native Lazarus/Fpc dialog that can be used to let the user select a directory? Note: no file, just the directory.

It's called TSelectDirectoryDialog in Lazarus.
However, if property names are different you still have to modify the code.

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160721/841eda06/attachment.html>

OK, found it.
I had to close Lazarus and then hand edit the lfm and pas files because Lazarus would not let me fix it within...

Cannot check if it will work the same yet because of the conditional errors checking the Delphi version.
But it seems like it does not have a property for the directory name, maybe I can use the FileName property instead?

For example:

  {$IF defined(FPC)}
    TMemIniFile.Create(IFile);
  {$ElseIf CompilerVersion >= 20} {Delphi 2009 = 20..}
    TMemIniFile.Create(IFile, TEncoding.UTF8);
  {$ELSE}
    TMemIniFile.Create(IFile);
  {$IFEND}

I do not understand from where it gets the error message about int64 and AnsdiString...

CompilerVersion is only defined by the Delphi compiler. An undefined macro is by default an empty string.
FPC uses FPC_FullVersion.

Mattias

[...] But it seems like it does not have a property for the directory name, maybe I can use the FileName property instead?

Yes.

Mattias

Mattias Gaertner wrote

> > But it seems like it does not have a property for the directory name, > > maybe I can use the FileName property instead? Yes.

That makes *no* sense for a class with the name TSelectDirectoryDialog??

Regards,
Graeme

TSelectDirectoryDialog is a specialized TOpenDialog.

TSelectDirectoryDialog = class(TOpenDialog)
TOpenDialog = class(TFileDialog)
TFileDialog = class(TCommonDialog)
...

Mattias

I know all that, I checked before I replied. My point is you have a DIRECTORY select dialog, but you have to use a Filename property to retrieve the selected Directory Name. Makes no sense.

If you must use the TFileDialog functionality, then at least add another class in the hierarchy (eg: TCustomFileDialog) where properties like "DefaultExt", "FileName", "Files" etc are not published. Then TSelectDirectoryDialog can descend from that, and then publish a "Directory" and "DirectoryList" (if multiple directory selection is supported) properties which internally reads the Filename value.

As it is now, the usage is messy.

Regards,
Graeme

It will break every existing program that uses this dialog (including the IDE).

As it is now, the usage is messy.

Unfortunately yes.

Bart

Bart wrote

It will break every existing program that uses this dialog (including the IDE).

The logic is broken already. So at least fix it for future releases. Not improving the LCL or fixing bugs (yes, I consider it a bug) is worse.

Regards,
Graeme

A directory is a file and has a filename.

The logic is that similar properties/methods have the same the name (e.g. Create, Clear, Caption, Filename). You don't need special names for specializations.

Bo found the Filename pretty fast himself and could use F1 to confirm.

Maybe you think it is a bug, because you are used to fpgui?

Mattias

If you're reading/assigning directory name in run-time (rather than design time), you could (conditionally for FPC) add a class helper for TSelectDirectoryDialog, emulating TFolderDialog the property

Something like this:

{$ifdef fpc}
  TSelectDirectoryDialogForFolderDialog = class helper for
TSelectDirectoryDialog
  private
    function GetDirName: string;
    procedure SetDirName(const AValue: string);
  public
    // the property name should match the one used for TFolderDialog
    // in order to prevent any changes in the code.
    property DirectoryName: string read GetDirName write SetDirName;
  end;
{$endif}
implementation
...
{$ifdef fpc}
function TSelectDirectoryDialogForFolderDialog.GetDirName: string;
begin
  Result:=Self.FileName;
end;
procedure TSelectDirectoryDialogForFolderDialogSetDirName(const AValue:
string);
begin
  Self.FileName:=Avalue;
end;
{$endif}

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20160722/5d0736be/attachment.html>

Mattias Gaertner wrote

Bo found the Filename pretty fast himself and could use F1 to confirm.

Yes, indeed it works and I concur that at least on Linux a directory is nothing but a special file so i am fine with the FileName property! :)

Delphi did not have a FolderSelect dialog at the time we needed it, but we found the one we used for so long on the net... Good that Lazarus/Fpc has one built in!

That is how I did it (using FPC rather than WINDOWS) and it works just fine. The GUI program now runs on Lazarus instead of Delphi 2007.

Maybe you think it is a bug, because you are used to fpgui?

I have to agree with Graeme here, this is just needlessly confusing. Which apparently the creator of TDirectoryEdit thought as well, as the property containing the selected directory is correctly called Directory there. I only ever use that or the SelectDirectory() wrapper function, so I've never noticed before how strange that dialog is.

A directory is a file and has a filename.

Not necessarily true on all file systems (both are directory entries, but that's about it), and also different from how naming this is treated everywhere else in the LCL.

Incidentally, in my opinion on Windows this component also invokes the wrong shell dialog. I believe it should use SHBrowseForFolder (which is explicitly for choosing a Folder) instead displaying a File selection dialog filtered to folders. But at least that's consistent with taking directories as files...

Regards,

Martok

Martok wrote

Incidentally, in my opinion on Windows this component also invokes the wrong shell dialog. I believe it should use SHBrowseForFolder (which is explicitly for choosing a Folder) instead displaying a File selection dialog filtered to folders. But at least that's consistent with taking directories as files...

If you mean this one http://mantis.freepascal.org/view.php?id=29736 then
you are wrong ;)

I see that open source projects have a disadvantage that sometimes the users tend to start flaming each other because of peanuts ;)

Ondrej

If you mean this one http://mantis.freepascal.org/view.php?id=29736 then you are wrong ;)

Wtf, MS? Not surprised nobody implemented this since Vista...

That being a recent change explains why I had a feeling this "worked" before.

I see that open source projects have a disadvantage that sometimes the users tend to start flaming each other because of peanuts ;)

Please believe me that while I still think this is a Bad Choice With Horrible UX, none of that was meant as a flame.

Sorry for coming over a bit aggressive, I may have been a bit ticked off by just how little sense that class design makes to me. But then again it really shouldn't as there are perfectly good wrappers for this that have proper terminology.

Regards,

Martok

Try the ofOldStyleDialog option.

No need to apologize, I didn't mean it against you (sorry if it looked like it). I just wrote it in the same email.

Ondrej

Ondrej Pokorny wrote

Try the ofOldStyleDialog option.

Almost. Needs two little changes, I've submitted a patch at <http://mantis.freepascal.org/view.php?id=30406>.
Let's continue over there.

No need to apologize, I didn't mean it against you (sorry if it looked like it). I just wrote it in the same email.

Alright then :)

Regards,

Martok