[SOLVED] Default to the W Alias inside the Windows unit?

[KodeZwerg]

Good day.

How do I tell my project that it use the W Aliases from the Windows API instead of the A Aliases?

By looking inside of Windows.pp I do see:

Code: Pascal  [Select][+][-]

1. {$ifdef FPC_OS_UNICODE}
2.   {$define UNICODE}
3. {$endif}
4.  
5. followed later by
6.  
7. {$ifdef UNICODE}
8. {$i unidef.inc}
9. {$else not UNICODE}
10. {$i ascdef.inc}
11. {$endif UNICODE}

By doing:

Code: Pascal  [Select][+][-]

1. unit Unit1;
2. {$DEFINE FPC_OS_UNICODE}
3. {$DEFINE UNICODE}
4. {$mode delphiunicode}
5. {$modeswitch m_default_unicodestring}

It still points me to the Ansi versions, but I want the Wide versions to be used without adding "W" to the API methods.

{$DEFINE FPC_OS_UNICODE}
{$define UNICODE}

inside Project Options / Custom Options / Conditionals       has also no effect.
Also the -WA switch has no effect.

What is the correct way of how it should be done please?

Answers that telling me to simply put a W at end I really not need to get.

Thanks in advance!


(At the end I want to have this behavior: a ctrl+click on "GetBinaryType" jumps into unidef.inc and of course uses it also)

[KodeZwerg]

Sorry, I forgot to tell, I am using Lazarus 2.3.0 (rev 3bdbedd91b) FPC 3.2.2 x86_64-win64-win32/win64 on a Windows 10 64bit machine.

[KodeZwerg]

Code: Pascal  [Select][+][-]

1. unit Unit1;
2. {$DEFINE FPC_OS_UNICODE}
3. {$DEFINE UNICODE}
4. {$mode delphiunicode}
5. {$modeswitch m_default_unicodestring}
6.  
7. interface
8.  
9. uses
10.   Windows ,
11.   Classes , SysUtils , Forms , Controls , Graphics , Dialogs;
12.  
13. type
14.  
15.   { TForm1 }
16.  
17.   TForm1 = class(TForm)
18.     procedure FormCreate(Sender: TObject);
19.   private
20.  
21.   public
22.  
23.   end;
24.  
25. var
26.   Form1: TForm1;
27.  
28. implementation
29.  
30. {$R *.lfm}
31.  
32. { TForm1 }
33.  
34. procedure TForm1.FormCreate(Sender: TObject);
35. begin
36.   // next line is my test line, a ctrl+click should point me to the unidef.inc declaration
37.   // how to do that please?
38.   GetBinaryType
39. end;
40.  
41. end.

[marcov]

There currently is no easy way.  While the Windows has some ifdef work, but probably too many other units depend on it being one byte, to simply enable it and recompile everything.

[tetrastes]

Good day.

How do I tell my project that it use the W Aliases from the Windows API instead of the A Aliases?

By looking inside of Windows.pp I do see:

Code: Pascal  [Select][+][-]

1. {$ifdef FPC_OS_UNICODE}
2.   {$define UNICODE}
3. {$endif}
4.  
5. followed later by
6.  
7. {$ifdef UNICODE}
8. {$i unidef.inc}
9. {$else not UNICODE}
10. {$i ascdef.inc}
11. {$endif UNICODE}

But at the second line below there is

Code: Pascal  [Select][+][-]

1. {$i redef.inc}

and in redef.inc

Code: Pascal  [Select][+][-]

1. function GetBinaryType(lpApplicationName: PChar; var lpBinaryType: DWORD): BOOL;external 'kernel32' name 'GetBinaryTypeA';

[KodeZwerg]

There currently is no easy way.  While the Windows has some ifdef work, but probably too many other units depend on it
being one byte, to simply enable it and recompile everything.

Thank you for your answer!
It's a little bit confusing why I can't activate it.
For the moment I patched the "Windows.pp" and added

Code: Pascal  [Select][+][-]

1. {$define FPC_OS_UNICODE} // this was added by me infront of the conditional UNICODE define
2.  
3. {$ifdef FPC_OS_UNICODE}
4.   {$define UNICODE}
5. {$endif}

I hope that I do not break anything by doing so...

But at the second line below there is

Code: Pascal  [Select][+][-]

1. {$i redef.inc}

and in redef.inc

Code: Pascal  [Select][+][-]

1. function GetBinaryType(lpApplicationName: PChar; var lpBinaryType: DWORD): BOOL;external 'kernel32' name 'GetBinaryTypeA';

Thank you for your answer!
I do not really understand your reply, my goal is/was to get

Code: Pascal  [Select][+][-]

1. function GetBinaryType(lpApplicationName:LPCWSTR; lpBinaryType:LPDWORD):WINBOOL; external 'kernel32' name 'GetBinaryTypeW';

(I just used exemplary the very first declaration, of course I do mean all "W" variants.)

[marcov]

After changes to windows unit, you must recompile the whole of FPC+lazarus, as many unit direct or indirectly will depend on windows.pp

redef.inc is a place where prototypes are placed that Delphi translated differently than most. Probably it needs work for unicode to work properly (the $ifdef unicode structure in the other files is from the windows headers)

[tetrastes]

But at the second line below there is

Code: Pascal  [Select][+][-]

1. {$i redef.inc}

and in redef.inc

Code: Pascal  [Select][+][-]

1. function GetBinaryType(lpApplicationName: PChar; var lpBinaryType: DWORD): BOOL;external 'kernel32' name 'GetBinaryTypeA';

Thank you for your answer!
I do not really understand your reply,

I meant that a ctrl+click jumps there by default (i.e. parameters types do not match exactly to those in ascdef.inc or unidef.inc), as in your example:

Code: Pascal  [Select][+][-]

1. procedure TForm1.FormCreate(Sender: TObject);
2. begin
3.   // next line is my test line, a ctrl+click should point me to the unidef.inc declaration
4.   // how to do that please?
5.   GetBinaryType
6. end;
7.  

But now I see that the main problem is not in this.

I managed to do what you want with this ugly hack:

Code: Pascal  [Select][+][-]

1. unit Unit1;
2. //{$mode delphi} - is not compiled
3. {$mode objfpc}  // windows.pp is in {$mode objfpc}
4. //{$modeswitch unicodestrings} - with this works also
5.  
6. interface
7.  
8. uses
9.   Windows ,
10.   Classes , SysUtils , Forms , Controls , Graphics , Dialogs;
11.  
12. {$define read_interface}
13. {$undef read_implementation}
14. {$i C:\lazarus\fpc\3.2.2\source\rtl\win\wininc\unidef.inc}
15.  
16. type
17.  
18.   { TForm1 }
19.  
20.   TForm1 = class(TForm)
21.     procedure FormCreate(Sender: TObject);
22.   private
23.  
24.   public
25.  
26.   end;
27.  
28. var
29.   Form1: TForm1;
30.  
31. implementation
32.  
33. {$undef read_interface}
34. {$define read_implementation}
35. {$i C:\lazarus\fpc\3.2.2\source\rtl\win\wininc\unidef.inc}
36.  
37. {$R *.lfm}
38.  
39. { TForm1 }
40.  
41. procedure TForm1.FormCreate(Sender: TObject);
42. var
43.     lpApplicationName: PWideChar; //or LPCWSTR;
44.     lpBinaryType: LPDWORD;
45. begin
46.   // next line is my test line, a ctrl+click should point me to the unidef.inc declaration
47.   // how to do that please?
48.   GetBinaryType(lpApplicationName, lpBinaryType);
49. end;
50.  
51. end.

It is even compiled (but not in mode delphi, note that windows.pp is in mode objfpc) and runs. 

[440bx]

Disclaimer: I haven't tried this therefore I don't know if it works or not.

If I were you I'd try creating a new installation using FPCUPDELUXE with the proper defines activated.  At least in theory and, with properly activated defines, that installation would default to the "W" functions.

HTH.

[KodeZwerg]

Disclaimer: I haven't tried this therefore I don't know if it works or not.

If I were you I'd try creating a new installation using FPCUPDELUXE with the proper defines activated.  At least in theory and, with properly activated defines, that installation would default to the "W" functions.

HTH.

Thanks for your response!
I did asked about that switch but did not get any answer.
So what I try to say, it wont install/compile.
But maybe you mean something different than the "Unicode"-Checkbox within setup of FpcUpdeluxe.

It is even compiled (but not in mode delphi, note that windows.pp is in mode objfpc) and runs. 

Thank you for your "hack", I like, love and use it!
Way better than patching and messing around in the RTL 

After changes to windows unit, you must recompile the whole of FPC+lazarus, as many unit direct or indirectly will depend on windows.pp

redef.inc is a place where prototypes are placed that Delphi translated differently than most. Probably it needs work for unicode to work properly (the $ifdef unicode structure in the other files is from the windows headers)

Again thank you very much for your help!

[440bx]

I did asked about that switch but did not get any answer.
So what I try to say, it wont install/compile.
But maybe you mean something different than the "Unicode"-Checkbox within setup of FpcUpdeluxe.

I don't know what effect the "unicode" checkbox has in fpcupdeluxe.  If memory serves, there is a place in fpcupdeluxe where one can _manually_ specify defines and compiler switches to be passed to the compiler.  If I am not mistaken and, that is correct, that's what I'd try.

Lastly, one comment.  From what you've said you're doing this because you don't want to hardcode the "A" or "W" of the Windows function being used.  Personally, I prefer hardcoding the "W" because it removes all possible ambiguities and serves as documentation.

It's different in C because in C, everything gets either re-wired (in the case of some libraries) or recompiled to ensure consistency, that is not the case in FPC.