Results 1 to 22 of 22

Thread: Firefox tab changer

  1. #1
    Join Date
    Jul 2008
    Posts
    12
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default Firefox tab changer

    *Edited From Documentation
    Code:
    function FindAndSetTarget(TitlePrefix: String; SetAsTarget: Boolean): Boolean;
    var
      T: TSysProcArr;
      I: Integer;
    begin
      T:= GetProcesses();
      for I := 0 to high(T) do
        if ExecRegExpr('^' + TitlePrefix, T[i].Title) then
        begin
          Result := True;
          if SetAsTarget then
          begin
            SetTarget(T[i]);
            ActivateClient;
          end;
        end;
      Writeln(T[i].handle);
      Writeln(T[i].Pid);
    end;
    Code:
    Program FFox;
    begin
      Wait(1000);
      FindandsetTarget('firefox',true)
    end;
    Trying to target a firefox window that doesn't say firefox in the title or the hwnd.
    Last edited by nemolorn; 06-02-2017 at 04:44 AM.

  2. #2
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    The regular expression will never match, because Firefox's windows are titled like this: "Webpage Title - Firefox". You are searching for a string that starts with "firefox" (lowercase).

    From IRC however it looks like the only window title remotely close to what he wants is "Webpage", as in it is truncated after the first space. Where is the implementation of the process functions? I had problems trying to retrieve window titles using the bare API myself, but it didn't fail like that.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  3. #3
    Join Date
    Jul 2008
    Posts
    12
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    With Just Yahoo.com open
    Code:
    Compiled successfully in 719 ms.
    [{TITLE = , HANDLE = 65754, PID = 5732, WIDTH = 1280, HEIGHT = 40}, 
    {TITLE = , HANDLE = 1050472, PID = 7416, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Simba - Untitled*, HANDLE = 263220, PID = 7416, WIDTH = 885, HEIGHT = 773}, 
    {TITLE = , HANDLE = 2229404, PID = 7416, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Bitmap conversion, HANDLE = 985306, PID = 7416, WIDTH = 320, HEIGHT = 240}, 
    {TITLE = , HANDLE = 2951964, PID = 7416, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Simba Extensions, HANDLE = 2099278, PID = 7416, WIDTH = 389, HEIGHT = 256}, 
    {TITLE = Simba, HANDLE = 918650, PID = 7416, WIDTH = 885, HEIGHT = 0}, 
    {TITLE = , HANDLE = 2032824, PID = 14156, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Yahoo, HANDLE = 3803990, PID = 14156, WIDTH = 1183, HEIGHT = 737},
    {TITLE = , HANDLE = 2361970, PID = 5732, WIDTH = 1264, HEIGHT = 945}, 
    {TITLE = , HANDLE = 1115314, PID = 1512, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Groove Music, HANDLE = 4589902, PID = 1512, WIDTH = 1200, HEIGHT = 901}, 
    {TITLE = MouseWithoutBorders, HANDLE = 459736, PID = 5732, WIDTH = 677, HEIGHT = 601}, 
    {TITLE = Settings, HANDLE = 1180548, PID = 1940, WIDTH = 1200, HEIGHT = 900}, 
    {TITLE = , HANDLE = 1115960, PID = 1512, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Settings, HANDLE = 525256, PID = 1512, WIDTH = 1200, HEIGHT = 901}, 
    {TITLE = , HANDLE = 65950, PID = 5732, WIDTH = 0, HEIGHT = 0}, 
    {TITLE = , HANDLE = 65944, PID = 5732, WIDTH = 1265, HEIGHT = 4}, 
    {TITLE = Program Manager, HANDLE = 196938, PID = 5732, WIDTH = 1280, HEIGHT = 1024}]
    Successfully executed.
    With Mozzilla Firefox Start Page Open

    Code:
    Compiled successfully in 437 ms.
    [{TITLE = , HANDLE = 65754, PID = 5732, WIDTH = 1280, HEIGHT = 40}, 
    {TITLE = Mouse without Borders 2.1.5.1103 - Settings, HANDLE = 526528, PID = 3940, WIDTH = 571, HEIGHT = 421}, 
    {TITLE = , HANDLE = 1050472, PID = 7416, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Simba - Untitled*, HANDLE = 263220, PID = 7416, WIDTH = 885, HEIGHT = 773}, 
    {TITLE = , HANDLE = 2229404, PID = 7416, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Bitmap conversion, HANDLE = 985306, PID = 7416, WIDTH = 320, HEIGHT = 240}, 
    {TITLE = , HANDLE = 2951964, PID = 7416, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Simba Extensions, HANDLE = 2099278, PID = 7416, WIDTH = 389, HEIGHT = 256}, 
    {TITLE = Simba, HANDLE = 918650, PID = 7416, WIDTH = 885, HEIGHT = 0},
     {TITLE = , HANDLE = 2032824, PID = 14156, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Mozilla Firefox Start Page - Mozilla Firefox, HANDLE = 3803990, PID = 14156, WIDTH = 1183, HEIGHT = 737}, 
    {TITLE = Groove Music, HANDLE = 2098378, PID = 13276, WIDTH = 1200, HEIGHT = 900}, 
    {TITLE = , HANDLE = 2361970, PID = 5732, WIDTH = 1264, HEIGHT = 945}, 
    {TITLE = , HANDLE = 1115314, PID = 1512, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Groove Music, HANDLE = 4589902, PID = 1512, WIDTH = 1200, HEIGHT = 901}, 
    {TITLE = MouseWithoutBorders, HANDLE = 459736, PID = 5732, WIDTH = 677, HEIGHT = 601}, 
    {TITLE = Settings, HANDLE = 1180548, PID = 1940, WIDTH = 1200, HEIGHT = 900}, 
    {TITLE = , HANDLE = 1115960, PID = 1512, WIDTH = 33, HEIGHT = 21}, 
    {TITLE = Settings, HANDLE = 525256, PID = 1512, WIDTH = 1200, HEIGHT = 901}, 
    {TITLE = , HANDLE = 65950, PID = 5732, WIDTH = 0, HEIGHT = 0}, 
    {TITLE = , HANDLE = 65944, PID = 5732, WIDTH = 1265, HEIGHT = 4}, 
    {TITLE = Program Manager, HANDLE = 196938, PID = 5732, WIDTH = 1280, HEIGHT = 1024}]
    Successfully executed.
    Last edited by nemolorn; 06-02-2017 at 04:58 AM.

  4. #4
    Join Date
    Jul 2008
    Posts
    12
    Mentioned
    0 Post(s)
    Quoted
    0 Post(s)

    Default

    *Workaround

    If a Target can be found once, it can be assigned a "constant" call for the duration of the script. This allows me to store 4 Targets that can be recalled and activated without a new search, and works around the case that the title of the target might have changed.

    Code:
    Var
    VM1, VM2,VM3,VM4 : Tsysproc;
    function FindAndSetTarget(TitlePrefix: String; SetAsTarget: Boolean; VMTarget:Integer): Boolean;
    
    begin
      T:= GetProcesses();
      for I := 0 to high(T) do
        if ExecRegExpr('^' + TitlePrefix, T[i].Title) then
        begin
          Result := True;
          if SetAsTarget then
            Case VMTarget of
              1 : begin
                    VMT1:= T[i];
                    SetTarget(T[i]);
                  end;
              2 : begin
                    VMT2:= T[i];
                    SetTarget(T[i]);
                  end;
              3 : begin
                    VMT3:= T[i];
                    SetTarget(T[i]);
                  end;
              4 : begin
                    VMT4:= T[i];
                    SetTarget(T[i]);
                  end;
        end;
      end;
      ActivateClient;
    end;

  5. #5
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by R0b0t1 View Post
    Where is the implementation of the process functions?
    https://github.com/MerlijnWajer/Simb...ndows.pas#L586

    pascal Code:
    SetLength(ProcArr[I].Title, 255);
    SetLength(ProcArr[I].Title, GetWindowText(Handle, PChar(ProcArr[I].Title), Length(ProcArr[I].Title)));
    Should not truncate unless the text length is longer than 255, at which point it should truncate it down to 255 chars. Maybe unicode title? Or the existence of a #0 char in the title which will cause it to not show the full text in the debugbox when printing it.
    GetWindowTextW (WideString) is probably better to use none the less.
    Last edited by slacky; 06-02-2017 at 07:41 PM.
    !No priv. messages please

  6. #6
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    https://github.com/MerlijnWajer/Simb...ndows.pas#L586

    pascal Code:
    SetLength(ProcArr[I].Title, 255);
    SetLength(ProcArr[I].Title, GetWindowText(Handle, PChar(ProcArr[I].Title), Length(ProcArr[I].Title)));
    Should not truncate unless the text length is longer than 255, at which point it should truncate it down to 255 chars. Maybe unicode title? Or the existence of a #0 char in the title which will cause it to not show the full text in the debugbox when printing it.
    GetWindowTextW (WideString) is probably better to use none the less.
    That must be it. The internal string for "Mozilla Firefox Start Page" is probably ANSI, but anything else is almost assuredly UTF-16. I'm not sure why some characters are displayed - the string should be empty (first byte #0).

    This bug seems to go along with Brandon's request for UTF-16 support. The best thing to do is only use UTF-16 to interface with Windows, and use UTF-8 internally. I think there is no good way to do this and it all needs to be done manually. If there's some way to make a unit which handles the wrapping of the Unicode Windows API that might be ideal.
    Last edited by R0b0t1; 06-02-2017 at 09:27 PM.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  7. #7
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    You can use the following code to convert to UTF16 and vice-versa to UTF8 on any platform.. I originally filed a bug for this on Simba's github but it didn't gain any momentum so I used the below code in the OpenGL plugins.. but now since Simba can interface directly with WinAPI and Java, it should technically have unicode support or at least functions to convert..

    You can translate these and use it directly in Simba.. otherwise write a plugin that contains the below code and voila..

    C++ Code:
    #if defined(_WIN32) || defined(_WIN64)
    int UTF8ToUTF16(char* utf8, wchar_t* utf16)
    {
        int len = MultiByteToWideChar(CP_UTF8, 0, utf8, -1, NULL, 0);
        if (utf16)
        {
            MultiByteToWideChar(CP_UTF8, 0, utf8, -1, utf16, len);
        }
        return len;
    }

    int UTF16ToUTF8(wchar_t* utf16, char* utf8)
    {
        int len = WideCharToMultiByte(CP_UTF8, 0, utf16, -1, NULL, 0, 0, 0);
        if (utf8)
        {
            WideCharToMultiByte(CP_UTF8, 0, utf16, -1, utf8, len, 0, 0);
        }
        return len;
    }
    #elif __cplusplus > 199711L
    int UTF8ToUTF16(char* utf8, wchar_t* utf16)
    {
        std::wstring result = std::wstring_convert<std::codecvt_utf8<wchar_t>>().from_bytes(std::string(utf8));
        if (utf16)
        {
            memcpy(utf16, &result[0], result.length() * sizeof(wchar_t));
        }
        return result.length();
    }

    int UTF8ToUTF16(wchar_t* utf16, char* utf8)
    {
        std::string result = std::wstring_convert<std::codecvt_utf8<wchar_t>>().to_bytes(std::wstring(utf16));
        if (utf8)
        {
            memcpy(utf8, &result[0], result.length() * sizeof(char));
        }
        return result.length();
    }
    #else
    int UTF8ToUTF16(char* utf8, wchar_t* utf16)
    {
        int utf8len = strlen(utf8);
        int utf16len = std::mbstowcs(NULL, utf8, utf8len);
        if (utf16)
        {
            std::mbstowcs(utf16, utf8, utf8len);
        }
        return utf16len;
    }

    int UTF16ToUTF8(wchar_t* utf16, char* utf8)
    {
        int utf16len = wcslen(utf16);
        int utf8len = std::wcstombs(NULL, utf16, utf16len);
        if (utf8)
        {
            std::wcstombs(utf8, utf16, utf16len);
        }
        return utf8len;
    }
    #endif
    I am Ggzz..
    Hackintosher

  8. #8
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    I've updated the bug on the issue tracker. @Brandon, can you comment on the best way to make sure all text is UTF-8 for internal use? This is the recommended way to use the Windows API. If it would just be going through the units that use Windows API functions that seems easy enough if slightly time consuming.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  9. #9
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    I added information to the following bugs:

    https://github.com/MerlijnWajer/Simba/issues/408
    https://github.com/MerlijnWajer/Simba/issues/338

    Even if you don't have time to help resolve the last one @Brandon you should comment on the proposed solution.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  10. #10
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by R0b0t1 View Post
    I added information to the following bugs:

    https://github.com/MerlijnWajer/Simba/issues/408
    https://github.com/MerlijnWajer/Simba/issues/338

    Even if you don't have time to help resolve the last one @Brandon you should comment on the proposed solution.

    The issue has been a long standing one. In all honesty, Simba really should only be using UTF8 but it NEEDS to support UTF-16 at the very least. That being said, it should have something like:

    String.utf16String(): WideString;
    WideString.utf8String(): String;


    Any WinAPI function Simba uses should be using UTF-16 (technically).. but can always explicitly call the "A" version of the function to get around the issue.

    For example:

    GetWindowTitleW
    GetWindowTitleA
    GetWindowTitle

    The W one is UTF-16. The A one is Ansi. The one without any suffix will choose whatever environment is being used at the time of compilation. So if Simba just so happened to be compiled with Unicode settings on, then TProcess will be using UTF-16. If Simba is compiled with Unicode off, then TProcess will use UTF-8 or ANSI..


    I vote for just exporting a function to do the conversions but also adding it to String and WideString.. then fixing WriteLn to use the appropriate one depending on what was passed to it. These issues are happening because we are stuffing UTF-16 into a String instead of WideString and when we call WriteLn in Simba, it terminates at the very first sign of a null character.. but most UTF-16 characters start with #0 (null) so Simba will never print them. That won't happen if Simba's WriteLn prints UTF-16 on Windows OR we add the conversions.


    Alternatively, we can use Simba 1.2+ and do it ourselves:

    Simba Code:
    const
      CP_ACP     = 0;                // default to ANSI code page
      CP_OEMCP   = 1;                // default to OEM (console) code page
      CP_UTF16   = 1200;             // utf-16 (Little Endian -- Most Windows Machines)
      CP_UTF16BE = 1201;             // unicodeFFFE (Big Endian -- Used in Bitmaps)
      CP_UTF7    = 65000;            // utf-7
      CP_UTF8    = 65001;            // utf-8
      CP_ASCII   = 20127;            // us-ascii
      CP_NONE    = $FFFF;            // rawbytestring encoding

    function _MultiByteToWideChar(CodePage: UInt32; dwFlags: DWORD; lpMultiByteStr: ^Char; cbMultiByte: Integer; lpWideCharStr: ^WideChar; cchWideChar: Integer): Integer; external 'MultiByteToWideChar@Kernel32.dll stdcall'
    function _WideCharToMultiByte(CodePage: UInt32; dwFlags: DWORD; lpWideCharStr: ^WideChar; cchWideChar: Integer; lpMultiByteStr: ^Char; cbMultiByte: Integer; lpDefaultChar: ^Char; lpUsedDefaultChar: ^Integer): Integer; external 'WideCharToMultiByte@Kernel32.dll stdcall'


    function UTF8ToUTF16(utf8: String): WideString;
    var
      len: Integer;
    begin
      len := _MultiByteToWideChar(CP_UTF8, 0, @utf8[1], -1, nil, 0);
      if (len > 0) then
      begin
        SetLength(result, len);
        _MultiByteToWideChar(CP_UTF8, 0, @utf8[1], -1, @result[1], len);
        SetLength(result, len - 1);
      end;
    end;

    function UTF16ToUTF8(utf16: WideString): String;
    var
      len: Integer;
    begin
      len := _WideCharToMultiByte(CP_UTF8, 0, @utf16[1], -1, nil, 0, nil, nil);
      if (len > 0) then
      begin
        SetLength(result, len);
        _WideCharToMultiByte(CP_UTF8, 0, @utf16[1], -1, @result[1], len, nil, nil);
        SetLength(result, len - 1);
      end;
    end;

    var
      Str: String;
      WStr: WideString;
      PC: PChar;

      i: Integer;
    begin
      Str := 'Hello World';

      WStr := UTF8ToUTF16(Str);
      PC := PChar(@WStr[1]);

      for i := 0 to high(Str) * sizeof(WideChar) do
      begin
        writeln(PC + i);
      end;

      Str := UTF16ToUTF8(WStr);
      PC := PChar(@Str[1]);

      for i := 0 to high(Str) * sizeof(Char) do
      begin
        writeln(PC + i);
      end;

      writeln('UTF8-String: ', Str);
      writeln('UTF16-String: ', WStr);
    end.


    But no one should have to do this in their scripts.. I'm not 100% sure why TProcess window title is utf-16 but that's expected on Windows..
    Last edited by Brandon; 06-07-2017 at 12:51 AM.
    I am Ggzz..
    Hackintosher

  11. #11
    Join Date
    Nov 2011
    Location
    England
    Posts
    3,072
    Mentioned
    296 Post(s)
    Quoted
    1094 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    ...
    Not sure TProcess got into this topic since it's nothing to do with window titles.

    Anyway Lape should export two methods:
    Simba Code:
    function UTF8Encode(const s : UnicodeString) : AnsiString;
    function UTF8Decode(const s : AnsiString): UnicodeString;

    And the Title field in the TSysProc should be changed to WideString with the internal method using the WideString variant.

  12. #12
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by Olly View Post
    Not sure TProcess got into this topic since it's nothing to do with window titles.

    Anyway Lape should export two methods:
    Simba Code:
    function UTF8Encode(const s : UnicodeString) : AnsiString;
    function UTF8Decode(const s : AnsiString): UnicodeString;

    And the Title field in the TSysProc should be changed to WideString with the internal method using the WideString variant.

    Always mix up TSysProc and TProcess.
    I am Ggzz..
    Hackintosher

  13. #13
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    The issue has been a long standing one. In all honesty, Simba really should only be using UTF8 but it NEEDS to support UTF-16 at the very least. That being said, it should have something like:

    String.utf16String(): WideString;
    WideString.utf8String(): String;


    Any WinAPI function Simba uses should be using UTF-16 (technically).. but can always explicitly call the "A" version of the function to get around the issue.
    What makes this "hard," or more likely annoying, is how the LCL wraps the WinAPI and seems to use UTF-16 everywhere (the LCL seems to have been developed almost solely with Windows in mind). Current development indicates that this is hard to design around. For some things (like TProcess) there are UTF-8 versions, but for some there aren't, and in the cases where there aren't I'm not sure what should happen. Do we copy the class and make a UTF-8 version? Do we ignore the fact the fields of a class are UTF-16 and re-encode them to UTF-8 to pass them to whatever LAPE variables they are bound to?

    Creating a custom UTF-8 version, if it has to happen, seems better.

    Quote Originally Posted by Brandon View Post
    For example:

    GetWindowTitleW
    GetWindowTitleA
    GetWindowTitle

    The W one is UTF-16. The A one is Ansi. The one without any suffix will choose whatever environment is being used at the time of compilation. So if Simba just so happened to be compiled with Unicode settings on, then TProcess will be using UTF-16. If Simba is compiled with Unicode off, then TProcess will use UTF-8 or ANSI..


    I vote for just exporting a function to do the conversions but also adding it to String and WideString.. then fixing WriteLn to use the appropriate one depending on what was passed to it. These issues are happening because we are stuffing UTF-16 into a String instead of WideString and when we call WriteLn in Simba, it terminates at the very first sign of a null character.. but most UTF-16 characters start with #0 (null) so Simba will never print them. That won't happen if Simba's WriteLn prints UTF-16 on Windows OR we add the conversions.
    What I'm hoping to do is make sure Simba never sees anything but UTF-8. We can still pass through the conversion functions (see below, they can be a wrapper around a cast) but it's possible to remove the need for Simba users to manage multiple encodings in most cases.

    Quote Originally Posted by Brandon View Post
    Alternatively, we can use Simba 1.2+ and do it ourselves:

    Simba Code:
    const
      CP_ACP     = 0;                // default to ANSI code page
      CP_OEMCP   = 1;                // default to OEM (console) code page
      CP_UTF16   = 1200;             // utf-16 (Little Endian -- Most Windows Machines)
      CP_UTF16BE = 1201;             // unicodeFFFE (Big Endian -- Used in Bitmaps)
      CP_UTF7    = 65000;            // utf-7
      CP_UTF8    = 65001;            // utf-8
      CP_ASCII   = 20127;            // us-ascii
      CP_NONE    = $FFFF;            // rawbytestring encoding

    function _MultiByteToWideChar(CodePage: UInt32; dwFlags: DWORD; lpMultiByteStr: ^Char; cbMultiByte: Integer; lpWideCharStr: ^WideChar; cchWideChar: Integer): Integer; external 'MultiByteToWideChar@Kernel32.dll stdcall'
    function _WideCharToMultiByte(CodePage: UInt32; dwFlags: DWORD; lpWideCharStr: ^WideChar; cchWideChar: Integer; lpMultiByteStr: ^Char; cbMultiByte: Integer; lpDefaultChar: ^Char; lpUsedDefaultChar: ^Integer): Integer; external 'WideCharToMultiByte@Kernel32.dll stdcall'


    function UTF8ToUTF16(utf8: String): WideString;
    var
      len: Integer;
    begin
      len := _MultiByteToWideChar(CP_UTF8, 0, @utf8[1], -1, nil, 0);
      if (len > 0) then
      begin
        SetLength(result, len);
        _MultiByteToWideChar(CP_UTF8, 0, @utf8[1], -1, @result[1], len);
        SetLength(result, len - 1);
      end;
    end;

    function UTF16ToUTF8(utf16: WideString): String;
    var
      len: Integer;
    begin
      len := _WideCharToMultiByte(CP_UTF8, 0, @utf16[1], -1, nil, 0, nil, nil);
      if (len > 0) then
      begin
        SetLength(result, len);
        _WideCharToMultiByte(CP_UTF8, 0, @utf16[1], -1, @result[1], len, nil, nil);
        SetLength(result, len - 1);
      end;
    end;

    var
      Str: String;
      WStr: WideString;
      PC: PChar;

      i: Integer;
    begin
      Str := 'Hello World';

      WStr := UTF8ToUTF16(Str);
      PC := PChar(@WStr[1]);

      for i := 0 to high(Str) * sizeof(WideChar) do
      begin
        writeln(PC + i);
      end;

      Str := UTF16ToUTF8(WStr);
      PC := PChar(@Str[1]);

      for i := 0 to high(Str) * sizeof(Char) do
      begin
        writeln(PC + i);
      end;

      writeln('UTF8-String: ', Str);
      writeln('UTF16-String: ', WStr);
    end.


    But no one should have to do this in their scripts.. I'm not 100% sure why TProcess window title is utf-16 but that's expected on Windows..
    You're right, no one should have to do this in their scripts. I'm trying to take it further and ensure that nobody needs to convert to or from the various Unicode encodings, as this is something that can (and should) be handled by the standard libraries and/or Simba.

    From FreePascal, all that needs to be done is this:

    Simba Code:
    var
      a: UnicodeString;
      b: UTF8String;

    begin
      a := (UnicodeString)b;
      b := (UTF8String)a;
    end.

    Unfortunately this might not work if the user is on Windows and using a rare code page, but we might not be able to design for this until we find a user who wants to use one of those languages.


    Quote Originally Posted by Olly View Post
    Not sure TProcess got into this topic since it's nothing to do with window titles.

    Anyway Lape should export two methods:
    Simba Code:
    function UTF8Encode(const s : UnicodeString) : AnsiString;
    function UTF8Decode(const s : AnsiString): UnicodeString;

    And the Title field in the TSysProc should be changed to WideString with the internal method using the WideString variant.
    The window title is recovered from TProcess and TProcess only returns UTF-16 data. Why it is forwarded to the interpreter with no conversion is strange, but that is what happens. If anyone has any idea of the places which use UTF-16 they should post so someone else or myself can start wrapping them with conversions to and from UTF-8/UTF-16.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  14. #14
    Join Date
    Nov 2011
    Location
    England
    Posts
    3,072
    Mentioned
    296 Post(s)
    Quoted
    1094 Post(s)

    Default

    Quote Originally Posted by R0b0t1 View Post
    The window title is recovered from TProcess and TProcess only returns UTF-16 data. Why it is forwarded to the interpreter with no conversion is strange, but that is what happens. If anyone has any idea of the places which use UTF-16 they should post so someone else or myself can start wrapping them with conversions to and from UTF-8/UTF-16.
    No, the window title is recovered from GetWindowText WinAPI. Check slacky's earlier reply (#5).

  15. #15
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    Quote Originally Posted by Olly View Post
    No, the window title is recovered from GetWindowText WinAPI. Check slacky's earlier reply (#5).
    Alright then, but it looks like TProcess in Simba is a copy of the TProcess in FreePascal/the LCL.

    I'm not sure what the fix is at the moment then because there are some things that you can't do with PChar and UTF-16 data. The result probably needs to be stored in a UnicodeString and cast to a UTF8String.
    Last edited by R0b0t1; 06-07-2017 at 02:03 PM.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  16. #16
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by R0b0t1 View Post
    Alright then, but it looks like TProcess in Simba is a copy of the TProcess in FreePascal/the LCL.

    I'm not sure what the fix is at the moment then because there are some things that you can't do with PChar and UTF-16 data. The result probably needs to be stored in a UnicodeString and cast to a UTF8String.
    Again, TProcess has NOTHING to do with this.. It's totally unrelated.. Nothing to do with the question at hand, nothing to do with window title. Nothing to do with this thread.

    TSysProc is the structure returned by GetProcesses. For further reading see my response here.
    Last edited by slacky; 06-12-2017 at 08:51 PM.
    !No priv. messages please

  17. #17
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    There's better ways to suggest I'd substituted in the wrong word in my comment, which I did.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  18. #18
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by R0b0t1 View Post
    There's better ways to suggest I'd substituted in the wrong word in my comment, which I did.
    Sorry, but it seemed like people who mentioned it (Olly did above, brandon also noted it) didn't get through to you, so I figured I had to be very clear, and a little harsh to get you to note it.
    !No priv. messages please

  19. #19
    Join Date
    Dec 2006
    Location
    Banville
    Posts
    3,914
    Mentioned
    12 Post(s)
    Quoted
    98 Post(s)

    Default

    It's just striking that for most of the questions I have asked the response has either been dismissive or confrontational. I was acquiring information about problems and asking for help, all of the other responses are navel gazing or criticism without many of the commenters providing part of a solution.

    People have recently questioned why there aren't many new members to the site, and this is why. Trying to learn about the projects associated with Villavu is hard because most of the active people are abrasive.
    The jealous temper of mankind, ever more disposed to censure than
    to praise the work of others, has constantly made the pursuit of new
    methods and systems no less perilous than the search after unknown
    lands and seas.

  20. #20
    Join Date
    May 2012
    Location
    Glorious Nippon
    Posts
    1,011
    Mentioned
    50 Post(s)
    Quoted
    505 Post(s)

    Default

    Quote Originally Posted by R0b0t1 View Post
    It's just striking that for most of the questions I have asked the response has either been dismissive or confrontational. I was acquiring information about problems and asking for help, all of the other responses are navel gazing or criticism without many of the commenters providing part of a solution.

    People have recently questioned why there aren't many new members to the site, and this is why. Trying to learn about the projects associated with Villavu is hard because most of the active people are abrasive.
    What are you talking about? You seem to be overreacting to nothing.
    Last edited by Citrus; 06-14-2017 at 01:31 PM.

  21. #21
    Join Date
    Jan 2007
    Posts
    8,876
    Mentioned
    123 Post(s)
    Quoted
    327 Post(s)

    Default

    Quote Originally Posted by Citrus View Post
    What are you talking about? You seem to be overreacting to nothing.
    He's just raising awareness to observed issues in this thread (and/or otherwise).
    Ironically, you're proving his point with that post

    Slacky's bulletpoints from the github link posted earlier sums this thread up nicely:
    Change Title field in TSysProc to WideString.
    Change it also for the lape export
    And finally replace this line with something along the lines of:
    SetLength(ProcArr[I].Title, GetWindowTextW(Handle, PWideChar(ProcArr[I].Title), Length(ProcArr[I].Title)));

  22. #22
    Join Date
    May 2012
    Location
    Glorious Nippon
    Posts
    1,011
    Mentioned
    50 Post(s)
    Quoted
    505 Post(s)

    Default

    Quote Originally Posted by Zyt3x View Post
    He's just raising awareness to observed issues in this thread (and/or otherwise).
    Ironically, you're proving his point with that post
    All I see is a normal discussion between robot, Brandon, and slacky. What issues?

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •