Re: yaqa-tkx; yet another question about Tkx
- From: "~greg" <g_m@xxxxxxxxxxxxxxxxxx>
- Date: Sat, 8 Mar 2008 05:57:38 -0500
"Jeff Hobbs" <jeff.hobbs@xxxxxxxxx> wrote in message news:d07e2c01-f8bf-49bc-b2ea-a2b169b7a8fd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 7, 12:09 pm, "~greg" <g...@xxxxxxxxxxxxxxxxxx> wrote:my $N = int( Tkx::i::call( $text, 'index', 'end'));
open FILE, ">$file2";
for(my $i=1; $i < $N; $i++)
{
my $line = Tkx::i::call( $text, 'get', "$i.0", "$i.end" );
print FILE "$line\n";
}
(note: trying to print FILE Tkx::i::call($text,'get',"$i.0","$i.end")
directly gets a "scalar in list context error" from Tkx::i::call)
... then the "problem" is that looping over the text contents
in this way will (sometimes?) return an extra line.
The Tk text widget has the last newline as part of the internal b-tree
for historical reasons. Is there a reason to loop over each line?
Otherwise what you want to do What you want to do is use
Tkx::i::call($text, 'get', "1.0", "end-1c"),
That works! Thanks! This works ....
open FILE, ">$file";
print FILE scalar( Tkx::i::call($text,'get','1.0','end-1c') );
close FILE;
....and the resulting file no longer has the annoying extra blank line.
(Without forcing that scalar context, all except a few spaces and brackes wind up lost, and the result is a usless mess. Likewise the text's 'dump' is useless.)
And yes, I do have reason to loop over each line. And apparently I have to do it this way ....
my $lines = Tkx::i::call ($text,'get','1.0','end-1c');
while($lines =~ /^(.*)$/gm) { .... }
which has the downside of essentially duplicating the text data in the $lines variable. Which was what I wanted to avoid, since these files will be quite large. But I can live with that. At least it's a lot better than what I was afraid I'd have to do - keep a perl array parallel to the text widget's contents.
BTW, I find your calling convention a bit odd from the intended design.Tkx::i::call( $text, 'insert', 'end', <FILE>);
Actually I've been using *tk = \&Tkx::i::call; so that I'd write that as
tk( $text, insert => 'end', <FILE>)
but I figured it was "odd", so, out of respect, I have been re-writing it Tkx::i::call() here.
The intended design is a bunch habits that have to be gotten into. Translations of Tcl into the underscore syntax. Using Tkx::widget to wrap paths. And dealing with things like $w->new_foo, $w->g_foo, $w->, and $w->foo.
And then the Tkx doc says things like:
If the method does not start with "new_" or have a prefix of the form /^_/ or /^[a-zA-Z]_/, then it is treated as if it had the "m_" prefix, i.e. the foo subcommand for the current widget is invoked.
Which is simple and clear enough.
But too much of that kind of thing, at one time, (3am kind of time)
begins to sound like a certain episode of Star Trek ...
"Of course, the uh... cards on uh... Beta Antares IV are different
- but not too different. Uh... the name of the game is called, uh... fizzbin."
"Fizzbin?"
"Fizzbin. It's, uh, not too difficult."
"Mm-hmm."
"Each player gets six cards, except for the dealer, uh, the player on the dealer's right, who, uh, gets seven."
"On the right?"
"Yes. The second card is turned up, except on Tuesdays."
"On Tuesday.""
"Mm-hmm. Oh, look what you got- two jacks! You got a half fizzbin already."
"Heh-heh!... I need another jack!"
"No, no, if you got another jack, why you'd have, uh, a shralk."
"A shralk?"
"Yes, you'd be disqualified."
"Oh."
"No, what you need now is either a king and a deuce- except at night, of course,when you'd need a queen and a, and a four."
"Except at night?"
"Right... oh, look at that- you got another jack! How lucky you are! How wonderful for you! Now, if you didn't get another jack, if you had gotten a king, why... then you'd get another card, except when it's dark, when you'd have to give it back. "
"If it were dark on Tuesday?"
"Yes, but what you're after is a royal fizzbin, but the odds in getting a royal fizzbin are astronom... Spock, what are the odds in getting a royal fizzbin?"
"I have never computed them, Captain."
"Well, they're astronomical, believe me." (pause) " Now, for the last card, we'll call it a kronk. You got that?"
"What?" (Kirk drops a card on the floor) "Oh, I'll get it..."
(reaches down, Kirk flips the table over and Spock treats the man to a Vulcan nerve pinch. The other guys get beaten up in a more conventional manner.)
Using Tkx::i::call(), or my shorthand tk() for it, avoids having to deal with any of that. Or delays having to deal with it. I may eventually come around to preferring the intended design.
But for the time being, while I am trying to learn Tk from the abundant Tcl documents, trying to use the intended design just amounts to having to deal with two learning curves, instead of one. It's just a trivial amount has to be learnt to do things the intended way. But you wouldn't believe how many very simple things, even about perl, I keep forgetting and have to constantly look up.
~~
And then there's an aesthetic consideration. I am finding that by only using Tkx::i::call, or my tk() function, all the code dealing with the GUI quite naturally and automatically falls neatly and clearly out of the way, and is keept distinct and apart from all the perl data-munching code. It just looks so much neater than anything I was able to write with Tk.pm. I am not sure I will want to give it up.
However, I am not going to argue this, at least until I've had lots more experience of both ways.
sincearly,
~greg
.
- References:
- yaqa-tkx; yet another question about Tkx
- From: ~greg
- Re: yaqa-tkx; yet another question about Tkx
- From: Jeff Hobbs
- yaqa-tkx; yet another question about Tkx
- Prev by Date: Re: question about ActiveState's Tkx
- Next by Date: Re: trying to get Zinc in
- Previous by thread: Re: yaqa-tkx; yet another question about Tkx
- Next by thread: entrycget w/ 'active'
- Index(es):
Relevant Pages
|
