[plt-scheme] scroll position with automatic scrollbars

From: pedro pinto (pedro.e.pinto at gmail.com)
Date: Thu Dec 7 23:13:23 EST 2006

Is there a way to figure out the current virtual x and virtual y position of
the (0,0) point of the client area when using automatic-scrollbars in a
canvas? I would like to use these values to optimize my rendering.

Thanks in advance,

-pp




On 12/7/06, plt-scheme-request at list.cs.brown.edu <
plt-scheme-request at list.cs.brown.edu> wrote:
>
> Send plt-scheme mailing list submissions to
>         plt-scheme at list.cs.brown.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> or, via email, send a message with subject or body 'help' to
>         plt-scheme-request at list.cs.brown.edu
>
> You can reach the person managing the list at
>         plt-scheme-owner at list.cs.brown.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of plt-scheme digest..."
>
>
> [Please handle PLT Scheme list administrative tasks through the Web:
>    http://list.cs.brown.edu/mailman/listinfo/plt-scheme]
>
>
> Today's Topics:
>
>    1. Re: [Mred] - syntax coloring in editor canvas (Robby Findler)
>    2. Re: Syntax objects and strings (or "stupid infix tricks")
>       (Corey Sweeney)
>    3. Shadowing syntax at the top (David Van Horn)
>    4. Re: Syntax objects and strings (or "stupid infix tricks")
>       (John Clements)
>    5. Re: Shadowing syntax at the top (Matthew Flatt)
>    6. double on-paint (pedro pinto)
>    7. Re: double on-paint (Matthew Flatt)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 7 Dec 2006 14:27:32 -0600
> From: Robby Findler <robby at cs.uchicago.edu>
> Subject: Re: [plt-scheme] [Mred] - syntax coloring in editor canvas
> To: "jack jack" <jack4746 at hotmail.com>
> Cc: plt-scheme at list.cs.brown.edu
> Message-ID: <20061207202734.1E2BB6C696 at laime.cs.uchicago.edu>
> Content-Type: text/plain; charset=UTF-8
>
> color:text does significantly more than what you write below. It takes
> a higher-level spec (namely a lexer spec), and it does the coloring
> online in an efficient manner.
>
> FWIW, that's the colorer that drscheme uses for its own code.
>
> Robby
>
> At Thu, 07 Dec 2006 21:05:28 +0100, "jack jack" wrote:
> > Here is what i got before viewing Framework GUI manual.
> > For the moment i used a button, but like you said, i could make the same
> > using after-insert.
> >
> > ;; changes style of the given word
> > (define (button_fonc x y)
> >   (let* ((txt (send Canvas1 get-editor))
> >          (mot (get-text-from-user "Color Test" "whichword"))
> >          (start (send txt find-string mot 'forward 0 'eof #t #f))
> >          (end (send txt find-string mot 'forward 0 'eof #f #f))
> >          ;(start (send txt get-start-position))
> >          ;(end (send txt get-end-position))
> >          (delta (make-object style-delta% )))
> >     (send delta set-weight-on 'bold)
> >     (send delta set-delta-foreground (make-object color% 255 0 0) )
> >     (send txt change-style  delta start end)))
> >
> >
> > Ok, I said i read the framework GUI (especially the color:text%), but i
> > didn't get the main idea of it (i'll retry tomorrow ;)).
> >
> > What would it bring me more than this code?
> >
> > Plus, text:color% seems to work with multiple lexeme values on a lexeme
> > whereas in the precedent source, i can make it without changing the
> > lexer/parser part of my code.
> >
> > As i said, i might have missed something with text:color% ;)
> >
> >
> > One more question, let such a definition be:
> >
> > (define if
> >    ....)
> >
> > in my case, define AND if would be colored, whereas only define should
> be...
> >
> > Could text:color% do the right job for me? :D
> >
> > _________________________________________________________________
> > Les révélations de la starac 6 commentées par Jérémy!
> > http://starac2006.spaces.live.com/
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 7 Dec 2006 14:46:11 -0600
> From: "Corey Sweeney" <corey.sweeney at gmail.com>
> Subject: Re: [plt-scheme] Syntax objects and strings (or "stupid infix
>         tricks")
> To: "Danny Yoo" <dyoo at hkn.eecs.berkeley.edu>
> Cc: PLT Scheme <plt-scheme at list.cs.brown.edu>
> Message-ID:
>         <d1c0755b0612071246h1790aac5g689c0f3f6ff2e489 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> That works.   (eval `(infix ,(read-syntax `thingy1 (open-input-string "(2
> +
> 3)")))) does produce 5.
>
> Thanks
>
> For fun I decided to test it's generality, I tried:
>
> (read-syntax `thingy2 (open-input-string "((("))
>
> Which immedately complained about missmatched parenthisis. I don't really
> need to do this, but do you know what one would one do if they needed to
> parse a language that didn't use parenthisis charactors in the traditional
> maner?
>
> Corey
>
>
>
> On 12/7/06, Danny Yoo <dyoo at hkn.eecs.berkeley.edu> wrote:
> >
> >
> >
> > > Is there a way to turn a string into a syntax object without calling
> > read?
> > > Something feels wrong with what i'm doing.  {I mean someting feels
> wrong
> > > beond the fact that i'm dealing with infix notation ;)}
> >
> > Hi Corey,
> >
> > The function READ-SYNTAX, coupled with making a string look like a port
> > through the OPEN-INPUT-STRING function, should do the trick.  Take a
> look
> > at READ-SYNTAX in the help desk first, because it needs to take an extra
> > argument, compared to regular READ.
> >
> >
> > > i've written a re-infixer that does the reverse of Dannys "infix"
> > > package.
> >
> > [some code cut]
> >
> > Ack!  I didn't mean for things to get this perverse.
> >
>
>
>
> --
> ((lambda (y) (y y)) (lambda (y) (y y)))
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://list.cs.brown.edu/pipermail/plt-scheme/attachments/20061207/94287ee3/attachment.html
>
> ------------------------------
>
> Message: 3
> Date: Thu, 07 Dec 2006 16:10:47 -0500
> From: David Van Horn <dvanhorn at cs.brandeis.edu>
> Subject: [plt-scheme] Shadowing syntax at the top
> To: plt-scheme at list.cs.brown.edu
> Message-ID: <ela018$bfo$1 at sea.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Welcome to DrScheme, version 360-svn20nov2006.
> Language: Standard (R5RS).
> > (define (let) (let))
> let: bad syntax in: (let)
>
> I'm pretty sure this should loop, and not be a syntax error.  Is this
> intended?
>
> David
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 7 Dec 2006 14:13:20 -0800
> From: John Clements <clements at brinckerhoff.org>
> Subject: Re: [plt-scheme] Syntax objects and strings (or "stupid infix
>         tricks")
> To: Corey Sweeney <corey.sweeney at gmail.com>
> Cc: Danny Yoo <dyoo at hkn.eecs.berkeley.edu>,     PLT Scheme
>         <plt-scheme at list.cs.brown.edu>
> Message-ID: <4430CFB5-0013-4667-84B0-F1C07B26F2F7 at brinckerhoff.org>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Dec 7, 2006, at 12:46 PM, Corey Sweeney wrote:
>
> > That works.   (eval `(infix ,(read-syntax `thingy1 (open-input-
> > string "(2 + 3)")))) does produce 5.
> >
> > Thanks
> >
> > For fun I decided to test it's generality, I tried:
> >
> > (read-syntax `thingy2 (open-input-string "((("))
> >
> > Which immedately complained about missmatched parenthisis. I don't
> > really need to do this, but do you know what one would one do if
> > they needed to parse a language that didn't use parenthisis
> > charactors in the traditional maner?
>
> You'd probably want to use a traditional parser.  One such parser is
> Scott Owens' parser-tools package, which (IIRC) is a part of the
> standard DrScheme distribution.
>
> HTH,
>
> John Clements
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2484 bytes
> Desc: not available
> Url :
> http://list.cs.brown.edu/pipermail/plt-scheme/attachments/20061207/35d52434/smime-0001.bin
>
> ------------------------------
>
> Message: 5
> Date: Fri, 8 Dec 2006 06:18:22 0800
> From: Matthew Flatt <mflatt at cs.utah.edu>
> Subject: Re: [plt-scheme] Shadowing syntax at the top
> To: David Van Horn <dvanhorn at cs.brandeis.edu>
> Cc: plt-scheme at list.cs.brown.edu
> Message-ID: <20061207221808.31F3765008F at mail-svr1.cs.utah.edu>
> Content-Type: text/plain; charset=UTF-8
>
> At Thu, 07 Dec 2006 16:10:47 -0500, David Van Horn wrote:
> > Welcome to DrScheme, version 360-svn20nov2006.
> > Language: Standard (R5RS).
> >  > (define (let) (let))
> > let: bad syntax in: (let)
> >
> > I'm pretty sure this should loop, and not be a syntax error.  Is this
> > intended?
>
> Yes, this is as intended.
>
> The new binding for `let' does not exist until the definition is
> evaluated, so the old definition of `let' applies when the RHS of the
> definition is expanded.
>
> It's possible for the expander to notice that `let' is being defined,
> and thus expand the RHS of the definition with the special assumption
> that `let' is a variable instead of a syntactic keyword. But then
> consider a pair of definitions grouped with `begin':
>
> (begin
>   (define (other) (let))
>   (define (let) 10))
>
> If you want this to work, then `begin' has to look ahead to other
> definitions before expanding a definition. That's certainly possible,
> but then it's no longer the case that wrapping a sequence of top-level
> forms with `begin' is the same as splicing the forms into the top
> level. So, the choice is to make this work or keep the splicing nature
> of `begin'. If you don't make it work but change the sngle-definition
> case, then it seems inconsistent to me. If you drop the splicing nature
> of `begin' then other dominoes start to fall over, such as the handling
> of `load' in a `begin' sequence.
>
> In short, the top level is hopeless. I'm not entirely happy with the
> current set of compromises, but I doubt that it's worth trying to
> change them.
>
> Matthew
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 7 Dec 2006 16:31:00 -0600
> From: "pedro pinto" <pedro.e.pinto at gmail.com>
> Subject: [plt-scheme] double on-paint
> To: plt-scheme at list.cs.brown.edu
> Message-ID:
>         <a9ba9b560612071431i19490c96qe9536a9c7f0d4759 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi there,
>
> On Windows XP, with DrScheme v360, the following code:
>
> (define f (new frame% (label "Hello")))
>
> (define c (new canvas% (parent f)
>                (paint-callback (lambda _ (printf "painting~n")))))
>
> (send f show #t)
>
> Will print "painting" twice, with a noticeable delay between the two
> messages, every time the frame is resized. That's not right is it?
>
> -pp
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://list.cs.brown.edu/pipermail/plt-scheme/attachments/20061207/381ecf79/attachment-0001.html
>
> ------------------------------
>
> Message: 7
> Date: Fri, 8 Dec 2006 06:48:54 0800
> From: Matthew Flatt <mflatt at cs.utah.edu>
> Subject: Re: [plt-scheme] double on-paint
> To: pedro.e.pinto at gmail.com
> Cc: plt-scheme at list.cs.brown.edu
> Message-ID: <20061207224842.2AEC9650097 at mail-svr1.cs.utah.edu>
> Content-Type: text/plain; charset=UTF-8
>
> At Thu, 7 Dec 2006 16:31:00 -0600, "pedro pinto" wrote:
> > On Windows XP, with DrScheme v360, the following code:
> >
> > (define f (new frame% (label "Hello")))
> >
> > (define c (new canvas% (parent f)
> >                (paint-callback (lambda _ (printf "painting~n")))))
> >
> > (send f show #t)
> >
> > Will print "painting" twice, with a noticeable delay between the two
> > messages, every time the frame is resized. That's not right is it?
>
> My guess is that both resize and refresh events from from the OS, and
> MrEd at some point triggers a refresh to handle the resize event. I may
> be able to improve that.
>
> Is the delay you see just a delay in DrScheme's output? I see a
> significant delay, too, but when I include the result of
> `(current-milliseconds)' in the printed message, then the printed
> numbers usually differ by only 20 or 30 milliseconds.
>
> Matthew
>
>
>
> End of plt-scheme Digest, Vol 16, Issue 14
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20061207/e3b329a0/attachment.html>

Posted on the users mailing list.