http://qs1969.pair.com?node_id=93534


in reply to Windows GUI programs in Perl

How close do you want to get to the OS? And if you want to get that close are you sure Perl is the best tool for the job?

I don't mean to flame, I mean to ask: what specifically do you want to do that you can't under vanilla Tk?

Replies are listed 'Best First'.
Re: (ichimunki) Re: Windows GUI programs in Perl
by John M. Dlugosz (Monsignor) on Jul 03, 2001 at 20:05 UTC
    Specifically: my immediate project is a funny-key-palatte like used in Mathematica. Based on a configuration text file, it shows a grid of buttons and clicking one sticks something on the system clipboard.

    The button face text and the clipboard text require Unicode support, since the whole point is to make easy access to things I can't type directly! That is, mathematical symbols, greek letters, funny arrows...

    Tk with geometry manager would be ideal to make the grid, and easy to program the application. But it failed the Unicode test—putting a (TM) symbol on a button showed 3 ASCII characters instead, taking the UTF encoding as individual 8-bit characters.

    —John

      I just saw your other post and realized this may be a large part of what you're dealing with.

      But aren't most of those characters (like math, arrows, and TM) available in regular fonts?

      For reference:
      #!/usr/bin/perl -w use strict; use Tk; my $mw = MainWindow->new(); my $text = $mw->Text()-> pack( -expand => 1, -fill => 'both' ); for my $x (0..255) { $text->insert( 'end', chr($x) ); } MainLoop;
      Obviously the Unicode stuff will need to mature somewhat. But if you are using this all from within Perl, maybe there is a way to cope for now?
        I think you mean "available in the currently selected code page" not in the font. Yes, the ™(TM) symbol is present in the A[0-F] range in the Western code page. I chose that one because, since it is indeed in the 8-bit character set, it will be present in every (normal) font. That way, I didn't have to worry about which font the demo program was using, reducing the problem space.

        A font will contain multiple encoding vectors, which map the character ordinal to a glyph (which has some internal ID). Latin-1, Latin-2, etc. may all be present in the same font file.

        The characters I'm interested in, ultimatly, are not in that Latin-1 range. That was just a simple test.

        I'm thinking the way to cope for now is to access the window handle and call SetWindowText directly, to draw the button faces. But my proof-of-concept is doing something funny...

        —John