[plt-scheme] WXME Decoding Error

From: Robby Findler (robby at cs.uchicago.edu)
Date: Tue Oct 14 13:45:31 EDT 2008

On Tue, Oct 14, 2008 at 12:40 PM, Eric Domeshek
<domeshek at stottlerhenke.com> wrote:
> Robby Findler wrote:
>> On Tue, Oct 14, 2008 at 11:08 AM, Eric Domeshek
>> <domeshek at stottlerhenke.com> wrote:
>>> 1- I also found the Finder chapter, and have calls to set up
>>> finder:default-extension and finder:default-filters.  However, these seem
>>> to
>>> only affect the Save/Save-As dialogs.  The Open dialog still comes up
>>> with
>>> "Any" as its only filter.  Is there a comparably simple way to set
>>> default
>>> filters on that dialog as well?
>> I recommend you just call the mred-level dialogs, instead of the
>> framework ones. The framework ones are legacy code now -- most (all?)
>> of the functionality is now at the mred layer.
> Interesting...  Is the whole Framework now considered deprecated legacy
> code, or just its file dialogs?

Just the file dialogs -- well there may be another corner I'd
disrecommend, but nothign comes to mind right away.

> I was using the Framework in an attempt to
> get a lot of basic functionality taken care of quickly.  In particular, I
> liked that it gave me all the basic menus with mostly sensible versions of
> their actions.  Is the recommendation that I use the Framework menus and the
> method file-menu:open-callback in order to set up a variant of
> handler:open-file that uses the GUI-level get-file and then calls
> "handler:edit-file to open the file, once the user has chosen it."?

handler:* is still good, yep.

>>> 2- After my now (mostly) successful file load, I'm still getting the
>>> following error message:
>>>> send: no such method: set-position for class: eer-pasteboard%
>>> Based on searching the docs, this method seems to be associated with
>>> scroll-event%s and text% editors.  So maybe there's somewhere else in the
>>> framework that is still expecting a text% object?  Any thoughts on what
>>> else
>>> I might have overlooked as a PLT GUI newbie?
>> This could easily be a bug in the framework. Do you get a stack trace?
>> Or perhaps do you have a small program that reproduces the problem?
> I'm not getting much of a useful error-report / stack-trace, which may be
> because of some try/catch forms I've got wrapped in various places.  I'll
> probably come back to this one another day, either to try to get a better
> trace and/or to build a simplified case...

Okay. I'll keep my eyes open too. I tried to be careful to keep the
generic editor-level functionality separate from the text- and
pasteboard- stuff, but the pasteboard-based stuff doesn't get used as
much so I could easily have made a mistake.


Posted on the users mailing list.