Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Michael Thompson]

> const SA = `
>   This is a multiline
>   string using hypothetical backticks.
>   Imagine it was fully syntax-highlighted
>   like normal strings and the comment
>   above are.
> `;

Also +1, though I'm less enthused about the syntax highlighting. That's
icing. Multiline strings are what I'm focused on.

Most of my apps either compile long SQL for generating data or long HTML
fragments for reporting.

I have 6 units chock full of SQL string fragments alone, and I shudder each
time I have to change a SQL.

Turning these fragments into a multitude of separate files doesn't sound
fun either, I'll have lost the ability to scroll through the unit trying to
find what constant I assigned that particular flavour of that sql...

Glad this topic is being discussed.

Many thanks

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Console encoding on Windows, output to file with ">"

[Michael Thompson]

On 3 May 2017 at 14:34, Ondrej Pokorny  wrote:

> > BUT when I redirect the output to a file with ">" :
> GermanTest.exe > GermanTest.txt I get corrupted characters
> "Ž„™”š á" (see attachment).
When I open the attachment on my PC, I see the correct characters:
[image: Inline images 1]

No idea what this means, just sharing info.

Good luck

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Math expressions in wiki

[Michael Thompson]

On Sun, Apr 16, 2017 at 3:09 AM Werner Pamler 
wrote:

> Thanks. Application of #2 is a bit complicated, but the results are very
> nice - see
> http://wiki.lazarus.freepascal.org/NumLib_Documentation#Gamma_function.
>

As an aside, just wanted to say thanks - that documentation looks awesome!
I see what you mean about the "strange function names" :-)

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Future of FPCUP tool

[Michael Thompson]

On 21 February 2015 at 03:45, Juha Manninen juha.mannine...@gmail.com
wrote:

 DonAlfredo appears to have motivation to maintain it.


That's not how I interpreted his posts, particularly his last one which he
might have posted after you sent this email...

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Windows DirectX9

[Michael Thompson]

On 7 December 2014 at 19:51, Adriaan van Os f...@microbizz.nl wrote:

 Michael Thompson wrote:

 The most up-to-date/maintained version ships with Pilot Logic's
 CodeTyphon.   Pilot Logic derived their version from the port by forum user
 TheBlackSheep, and in turn TheBlackSheep derived his version from the one
 listed above.


 Thanks for the hint, but I couldn't find DirectX in the Pilot Logic's
 CodeTyphon downloads.


Hmm.  I admit it's been a year since I last checked, but there were two
packages you need.  PL_Win_DirectShow and PL_Win_DirectX.  The forum
entries for each are still valid, and don't mention the packages have been
removed.

From the change log http://www.pilotlogic.com/codetyphon/changeslog.txt
DirectX was last updated in January 2014.  So it should be there.

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Windows DirectX9

[Michael Thompson]

On 8 December 2014 at 08:19, Michael Thompson mike.cornfl...@gmail.com
 wrote:

 On 7 December 2014 at 19:51, Adriaan van Os f...@microbizz.nl wrote:

 Michael Thompson wrote:

 The most up-to-date/maintained version ships with Pilot Logic's
 CodeTyphon.   Pilot Logic derived their version from the port by forum user
 TheBlackSheep, and in turn TheBlackSheep derived his version from the one
 listed above.


 Thanks for the hint, but I couldn't find DirectX in the Pilot Logic's
 CodeTyphon downloads.


 Hmm.  I admit it's been a year since I last checked, but there were two
 packages you need.  PL_Win_DirectShow and PL_Win_DirectX.  The forum
 entries for each are still valid, and don't mention the packages have been
 removed.

 From the change log http://www.pilotlogic.com/codetyphon/changeslog.txt 
 DirectX
 was last updated in January 2014.  So it should be there.


Ah, think I might know what the issue is.  Near as I can make out,
PilotLogic do not provide individual download for each of the modules.
It's one big fat half gig download :-(  *Everything* is in that download.

I made my own copy in July as part of an idea I'm working on.  Currently
out of time for the wider project, but the two PilotLogic modules are
there.  I've made a minor change to DirectShow to enable the SampleGrabber
to work in wider situations...  There *may* be other minor changes, but I
think I applied those at the application level...

http://sourceforge.net/p/lazarusvideoutilities/code/HEAD/tree/trunk/Packages/

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Windows DirectX9

[Michael Thompson]

On 28 November 2014 at 23:25, Adriaan van Os f...@microbizz.nl wrote:

 Looking on the internet for DirectShow Pascal bindings, I came across 
 http://code.google.com/p/dspack/source/browse/#svn%
 2Ftrunk%2Fsrc%2FDirectX9. With a few modifications, this does compile
 with fpc-2.6.4, e.g.


There are different versions of DSPack available.  When I last checked a
year or two ago, this is one of the staler ones.

The most up-to-date/maintained version ships with Pilot Logic's CodeTyphon.
  Pilot Logic derived their version from the port by forum user
TheBlackSheep, and in turn TheBlackSheep derived his version from the one
listed above.

Note: CodeTyphon uses trunk, so their version of DSPack will always compile
against that.

Cheers

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Regionalisation (Was ThousandSeparator)

[Michael Thompson]

On 26 November 2014 at 23:54, Hans-Peter Diettrich drdiettri...@aol.com
wrote:

 Conclusion:
 Proper handling of separators in formatted numbers is essential, or else
 users may run into so big trouble, that they will drop your program as
 unusable.

 DoDi


(renamed subject due to change in topic)

I hear you, but this issue is so much wider than separators.  I know one
software package that will only successfully export data to excel if the
system regional is one of the English (xxx) variations (Australian
guaranteed to work, not really played with the rest...).  In this case, the
client (in Denmark) has one PC in a corner, set to Australian settings,
just for exports...

As an Australian developer, this is just embarrassing...

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] The mysterious case of the double TOC

[Michael Thompson]

 Had a look at a TOC from a lazdoc-generated LCL.CHM and yes:
 param name=Name value=Classes and Objects, by Unit, line 11
 then value=TForm on line 1336
 param name=Name value=Alphabetical Classes and Objects List, line
3825
 then value=TForm on line 52547

Nicely found.  I potentially see benefit from the multiple entries in the
TOC as show above (presuming those categories are available elsewhere in
the viewer).   Perhaps all that's required is adding that Category as a new
column in the ListView?

Mike
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] UTF8 support for win\process.inc

[Michael Thompson]

G'day,

I'm on Windows 8/Trunk FPC

Been banging my head against the wall all weekend trying to get some UTF8
working with the LazUtils TProcessUTF8.  By the end of that I realized no
matter what I did there, I wasn't going to get anywhere.

I've now solved my problem using only TProcess.  See below for the modified
TProcess.Execute (win\process.inc)

Procedure TProcess.Execute;
Var
  i : Integer;
  PName,PDir,PCommandLine : PWideChar; // Changed from PChar
  FEnv: pointer;
  FCreationFlags : Cardinal;
  FProcessAttributes : TSecurityAttributes;
  FThreadAttributes : TSecurityAttributes;
  FProcessInformation : TProcessInformation;
  FStartupInfo : STARTUPINFO;
  HI,HO,HE : THandle;
  Cmd : String;

begin
  PName:=Nil;
  PCommandLine:=Nil;
  PDir:=Nil;

  if (FApplicationName='') and (FCommandLine='') and (FExecutable='') then
Raise EProcess.Create(SNoCommandline);
  if (FApplicationName'') then
begin
PName:=PWideChar(UTF8Decode(FApplicationName));   // Added UTF8Decode
PCommandLine:=PWideChar(UTF8Decode(FCommandLine));// Added UTF8Decode
end
  else If (FCommandLine'') then
PCommandLine:=PWideChar(UTF8Decode(FCommandLine)) // Added UTF8Decode
  else if (Fexecutable'') then
begin
Cmd:=MaybeQuoteIfNotQuoted(Executable);
For I:=0 to Parameters.Count-1 do
  Cmd:=Cmd+' '+MaybeQuoteIfNotQuoted(Parameters[i]);
PCommandLine:=PWideChar(UTF8Decode(Cmd)); // Added UTF8Decode
end;
  If FCurrentDirectory'' then
PDir:=PWideChar(UTF8Decode(FCurrentDirectory));   // Added UTF8Decode
  if FEnvironment.Count0 then
FEnv:=StringsToPChars(FEnvironment)
  else
FEnv:=Nil;
  Try
FCreationFlags:=GetCreationFlags(Self);
InitProcessAttributes(Self,FProcessAttributes);
InitThreadAttributes(Self,FThreadAttributes);
InitStartupInfo(Self,FStartUpInfo);
If poUsePipes in FProcessOptions then
  CreatePipes(HI,HO,HE,FStartupInfo,Not(poStdErrToOutPut in
FProcessOptions), FPipeBufferSize);
Try
  If Not
CreateProcessW(PName,PCommandLine,@FProcessAttributes,@FThreadAttributes,
   FInheritHandles,FCreationFlags,FEnv,PDir,FStartupInfo,
   fProcessInformation) then
 // Changed to CreateProcessW
Raise
EProcess.CreateFmt(SErrCannotExecute,[FCommandLine,GetLastError]);
  FProcessHandle:=FProcessInformation.hProcess;
  FThreadHandle:=FProcessInformation.hThread;
  FProcessID:=FProcessINformation.dwProcessID;
Finally
  if POUsePipes in FProcessOptions then
begin
FileClose(FStartupInfo.hStdInput);
FileClose(FStartupInfo.hStdOutput);
if Not (poStdErrToOutPut in FProcessOptions) then
  FileClose(FStartupInfo.hStdError);
CreateStreams(HI,HO,HE);
end;
end;
FRunning:=True;
  Finally
If FEnvNil then
  FreeMem(FEnv);
  end;
  if not (csDesigning in ComponentState) and // This would hang the IDE !
 (poWaitOnExit in FProcessOptions) and
  not (poRunSuspended in FProcessOptions) then
WaitOnExit;
end;

Basically I changed 3 x PChar to PWideChar, then when the PWideChars are
being set I do it via PWideChar(UTF8Decode(string))
Finally I changed CreateProcess to CreateProcessW.

I had thought I was going to need to change the datatypes for FCommandline
etc, but this wasn't the case.

With the limited testing I've done, this seems to successfully enable UTF8
support within TProcess, without the end user needing to change any of
their code.  Also, this doesn't seem to break any existing code that uses
TProcess.

Before I submit this as a patch though, I have concerns.  Mainly around a)
not knowing your development plans in this area and b) me not really
knowing unicode (just because this works, doesn't mean it's right).

A summary of my concerns:
* I note in redef.inc there is already a redirect for CreateProcess to
CreateProcessW.  This implies to me there is already a plan in mind, and I
might be cutting across that by directly calling CreateProcessW.
* My code doesn't take UTF16 into account.  In truth, I'm not sure how to
do that.
* I've only done limited testing on a Win 8 64bit PC set to Australian
regional settings.  Really I think I need to test this on a wide variety of
regional settings and across a variety of Win OS's...

Before I submit a patch based on this can anyone tell me if I'm on the
wrong track? (and if so, where)

Many thanks

Mike Thompson
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] UTF8 support for win\process.inc

[Michael Thompson]

Apologies, I forgot to include a link to just the patch...

https://dl.dropboxusercontent.com/u/59503182/fpc/process.inc.patch

Mike T


On 1 July 2014 16:45, Michael Thompson mike.cornfl...@gmail.com wrote:

 G'day,

 I'm on Windows 8/Trunk FPC

 Been banging my head against the wall all weekend trying to get some UTF8
 working with the LazUtils TProcessUTF8.  By the end of that I realized no
 matter what I did there, I wasn't going to get anywhere.

 I've now solved my problem using only TProcess.  See below for the
 modified TProcess.Execute (win\process.inc)

 Procedure TProcess.Execute;
 Var
   i : Integer;
   PName,PDir,PCommandLine : PWideChar; // Changed from PChar
   FEnv: pointer;
   FCreationFlags : Cardinal;
   FProcessAttributes : TSecurityAttributes;
   FThreadAttributes : TSecurityAttributes;
   FProcessInformation : TProcessInformation;
   FStartupInfo : STARTUPINFO;
   HI,HO,HE : THandle;
   Cmd : String;

 begin
   PName:=Nil;
   PCommandLine:=Nil;
   PDir:=Nil;

   if (FApplicationName='') and (FCommandLine='') and (FExecutable='') then
 Raise EProcess.Create(SNoCommandline);
   if (FApplicationName'') then
 begin
 PName:=PWideChar(UTF8Decode(FApplicationName));   // Added UTF8Decode
 PCommandLine:=PWideChar(UTF8Decode(FCommandLine));// Added UTF8Decode
 end
   else If (FCommandLine'') then
 PCommandLine:=PWideChar(UTF8Decode(FCommandLine)) // Added UTF8Decode
   else if (Fexecutable'') then
 begin
 Cmd:=MaybeQuoteIfNotQuoted(Executable);
 For I:=0 to Parameters.Count-1 do
   Cmd:=Cmd+' '+MaybeQuoteIfNotQuoted(Parameters[i]);
 PCommandLine:=PWideChar(UTF8Decode(Cmd)); // Added UTF8Decode
 end;
   If FCurrentDirectory'' then
 PDir:=PWideChar(UTF8Decode(FCurrentDirectory));   // Added UTF8Decode
   if FEnvironment.Count0 then
 FEnv:=StringsToPChars(FEnvironment)
   else
 FEnv:=Nil;
   Try
 FCreationFlags:=GetCreationFlags(Self);
 InitProcessAttributes(Self,FProcessAttributes);
 InitThreadAttributes(Self,FThreadAttributes);
 InitStartupInfo(Self,FStartUpInfo);
 If poUsePipes in FProcessOptions then
   CreatePipes(HI,HO,HE,FStartupInfo,Not(poStdErrToOutPut in
 FProcessOptions), FPipeBufferSize);
 Try
   If Not
 CreateProcessW(PName,PCommandLine,@FProcessAttributes,@FThreadAttributes,
FInheritHandles,FCreationFlags,FEnv,PDir,FStartupInfo,
fProcessInformation) then
  // Changed to CreateProcessW
 Raise
 EProcess.CreateFmt(SErrCannotExecute,[FCommandLine,GetLastError]);
   FProcessHandle:=FProcessInformation.hProcess;
   FThreadHandle:=FProcessInformation.hThread;
   FProcessID:=FProcessINformation.dwProcessID;
 Finally
   if POUsePipes in FProcessOptions then
 begin
 FileClose(FStartupInfo.hStdInput);
 FileClose(FStartupInfo.hStdOutput);
 if Not (poStdErrToOutPut in FProcessOptions) then
   FileClose(FStartupInfo.hStdError);
 CreateStreams(HI,HO,HE);
 end;
 end;
 FRunning:=True;
   Finally
 If FEnvNil then
   FreeMem(FEnv);
   end;
   if not (csDesigning in ComponentState) and // This would hang the IDE !
  (poWaitOnExit in FProcessOptions) and
   not (poRunSuspended in FProcessOptions) then
 WaitOnExit;
 end;

 Basically I changed 3 x PChar to PWideChar, then when the PWideChars are
 being set I do it via PWideChar(UTF8Decode(string))
 Finally I changed CreateProcess to CreateProcessW.

 I had thought I was going to need to change the datatypes for FCommandline
 etc, but this wasn't the case.

 With the limited testing I've done, this seems to successfully enable UTF8
 support within TProcess, without the end user needing to change any of
 their code.  Also, this doesn't seem to break any existing code that uses
 TProcess.

 Before I submit this as a patch though, I have concerns.  Mainly around a)
 not knowing your development plans in this area and b) me not really
 knowing unicode (just because this works, doesn't mean it's right).

 A summary of my concerns:
 * I note in redef.inc there is already a redirect for CreateProcess to
 CreateProcessW.  This implies to me there is already a plan in mind, and I
 might be cutting across that by directly calling CreateProcessW.
 * My code doesn't take UTF16 into account.  In truth, I'm not sure how to
 do that.
 * I've only done limited testing on a Win 8 64bit PC set to Australian
 regional settings.  Really I think I need to test this on a wide variety of
 regional settings and across a variety of Win OS's...

 Before I submit a patch based on this can anyone tell me if I'm on the
 wrong track? (and if so, where)

 Many thanks

 Mike Thompson


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel