MetaCard List Digest     Monday, October 23 2000     Volume 04 : Number 016




----------------------------------------------------------------------

Date: Sat, 21 Oct 2000 13:12:34 +0200
From: Till <[EMAIL PROTECTED]>
Subject: report generator stack

I tried the stack but had several problems:

- - with MetaCard 2.3.1 "...Close the report space by clicking on its
close
box which will reopen the main report generator window." does not work
because there is no close box. I couldn't close the window with the menu

either. - This works in Version 2.3
- - when I define the size of fields in the editing window, then close and

reopen it the field size is reduced. So I can never get a full page size

report.
(I am working with A4 as paper size)

Thanks for hints where I make the mistakes

Till Bandi



[EMAIL PROTECTED] wrote:

> There is a report generator stack available(mcrg.mc) from
> ftp://ftp.metacard.com/metacard/
> as well as a script you can use to print fields in MC 2.3. See the
> scripts of the print field utility stack included with MC 2.3.
>
> regards,
> Tuviah Snyder
> Diskotek
> Custom Application Development & SuperCard/HyperCard Conversion at a
low
> price
> Web: http://members.aol.com/diskotek1/  ICQ:66810408  Fax: (505)
218-2902
>
> Archives: http://www.mail-archive.com/metacard%40lists.best.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <[EMAIL PROTECTED]>, not this list.

------------------------------

Date: Sat, 21 Oct 2000 21:18:54 +0200
From: "Jose L. Rodriguez Illera" <[EMAIL PROTECTED]>
Subject: Re: New  game with MC - puzzle stack

Hi Wilhlem,

Thank you for your input. Your script seems good for puzzles of different
number of rows and columns. I will try it.

The potential problems you find in btn 'crear rompecabezas' are an old
version of the sciling process not deleted (sorry!). You may see that the
call for the button script is commented and not used. The slicing process is
done through the handler 'crear' in the stack script and is independent of
the number of pieces, and does not use long script lines.

Of course, I agree with you in the necessity of sharing more stacks and even
more 'widgets': not need to reinvent the wheel every time.

Regards,

Jose Luis

- -------------
Jos� L. Rodr�guez Illera
Universitat de Barcelona
 




- -----------

el 21/10/00 17:09, MetaCard List Digest en
[EMAIL PROTECTED] escribi�:

> ------------------------------
> 
> Date: Fri, 20 Oct 2000 20:38:24 +0200
> From: Wilhelm Sanke <[EMAIL PROTECTED]>
> Subject: Re: New  game with MC - puzzle stack
> 
>> Date: Mon, 16 Oct 2000 13:32:41 +0200
>> From: "Jose L. Rodriguez Illera" <[EMAIL PROTECTED]>
>> Subject: New  game with MC
> 
>> Anyone interested may download a new puzzle game from the XWorlds site.
> It
>> makes a puzzle from any image using 'import snapshot' command, with
>> different sizes and number of pieces. Simple but works smooth.
> 
>> Regards,
> 
>> Jose Luis
> 
> Hi, Jose Luis,
> 
> as we use a Metacard puzzle generator - also using "import snapshot" -
> among the examples in our multimedia courses here, I was very curious to
> have a look at your stack at the XWorlds site.
> 
> I like the overall structure of your stack and I learned a few things.
> To use a "clipped" tabbed menu button (btn "Piezas") for the value imput
> is a really a good idea. We have so far used a pulldown menu button for
> input of preset values or an input field for the free choice of values.
> 
> Your "slicing" button (btn "crear rompecabezas") shows the problems you
> may run into when trying to determine the rects of the image tiles. For
> the sake of comparison and for you - and anybody who is interested - to
> try out, here is the slicing part of my version of a puzzle generator
> that
> - - allows the input of any number for rows and columns and can thus be
> also adapted to various proportions of images
> - - is very compact because of using arrays - avoiding the need for long
> script lines ("select..and..and.." etc.):
> 
> "on mouseUp
> #=="slicing" images for puzzles==computing and importing tiles==
> #==for any (equal or different) number of rows and columns==
> #== FX = horizontal number of tiles; FY = vertical number of tiles
> #==values for FX and FY to be transferred from an "input" handler
> Global FX,FY
> put the rect of image 1 into imagerect # image to be sliced
> put item 3 of imagerect - item 1 of imagerect into DiffX
> put item 4 of imagerect - item 2 of imagerect into DiffY
> #== "div" instead of "/" produces pixel-exact borderless tiles
> #== for all image sizes==
> put DiffX div FX into tilewidthX
> put DiffY div FY into tileheightY
> #==arrays: compute points of tile rects ==
> put item 1 of imagerect into X[1]
> put item 2 of imagerect into Y[1]
> repeat with i = 1 to FX
> put X[1] + (tilewidthX * i) into X[i + 1]
> end repeat
> repeat with i = 1 to FY
> put Y[1] + (tileheightY * i) into Y[i + 1]
> end repeat
> put 0 into TileN # tile number
> put the windowID of this stack into StackID
> lock screen
> # ==set tile rects and do snapshots==
> repeat with a = 1 to FY
> repeat with b = 1 to FX
> add 1 to TileN
> put x[b] into item 1 of tilerect
> put y[a] into item 2 of tilerect
> put x[b+1] into item 3 of tilerect
> put y[a+1] into item 4 of tilerect
> import snapshot from rect TileRect of window StackID
> put "T"&TileN into Tile          # to name tiles (needed later for
> puzzle script)
> set the name of last image to Tile
> set the topleft of image Tile to item 1 to 2 of tilerect  # set
> tile position
> end repeat
> end repeat
> choose browse tool
> end mouseUp"
> - ---
> Maybe I should offer my puzzle package for inspection at the XWorlds
> site, too, but I first need to produce a externally presentable version
> without German terms. I'll ask Kevin Miller about that.
> 
> Generally, I think, it would be helpful to exchange *more* stacks among
> the lists members - and for new Metacard users - as on the Metacard and
> XWorlds sites. By the way, there have been no new entries in the
> "contrib" folder of the Metacard ftp-site since April 1999.
> 
> The same holds for sample scripts; what about setting up an annotated
> and topic-sorted script library? There are already a number around in
> the list-archives and surely many more that could be shared.
> 
> 
> Regards,
> Wilhelm Sanke
> Zentraler Medienbereich (University Media Center)
> University of Kassel / Germany

- -- 

------------------------------

Date: Sat, 21 Oct 2000 18:37:42 -0400 (EDT) 
From: andu <[EMAIL PROTECTED]>
Subject: test

where am I?

Regards, Andu 
_______________________
[EMAIL PROTECTED]

------------------------------

Date: Sat, 21 Oct 2000 21:05:39 -0500
From: Tariel Gogoberidze <[EMAIL PROTECTED]>
Subject: Find in ScriptEditor

Platform - Mac OS v. 7.6.1 and/or v9.1

In latest MetaCard beta 2.3.2B3, when you are using "Script find" substack  in "Script 
Editor"  (
the one that pops up when you are choosing "Find..." under Tools menu in Script 
Editor) -- you
have to click TWICE on "Find next" button to find next search word in script. In 
earlier versions
of MC it was just selecting next search word. Farther, it leaves pervious found words 
selected
after it selects the next one. As a result you have several "noncontinuguos" hilites 
of your
search words in the script editor window. It could be a nice feature (having all your 
search
words selected in the "Script editor" window...) but the script in button "Find 
Next.." of
"Script find" stack  is identical in MetaCard v. 2.3 and in 2.3.2B3 and the  
"noncontinuguos
hilites" property in Script Editors field is not checked - so, I wonder -- is it a 
general change
in MetaCard engine behavior when you are using script similar to one found in "Find 
next.."
button of "Script find" stack?
Tariel Gogoberidze

------------------------------

Date: Sat, 21 Oct 2000 21:34:16 -0400
From: "Raymond E. Griffith" <[EMAIL PROTECTED]>
Subject: windowBoundingRect

I would like to comment on this feature, which is described in the docs this
way:

The global "windowBoundingRect" property specifies the rectangle in
which all windows must open.  By default it is the same as the
screenRect minus the size of the menubar (on Mac) or task bar (on
Windows), but can be made smaller to support UI features like tool
bars.

This property now makes it exceedingly difficult to print full pages if your
screen is set to, say, 800 x 600. The windowBoundingRect is 0,20,640,480.

I believe this property, while meant to be a good feature, is a bad idea.

I have a stack I have created to hold formatted data for printing. The rect
of the stack is -- or *was* -- 468 x 648. This is the printing area of a
letter sized sheet of paper with an inch margin all around. MC 2.3.2 now
consistently cuts this off, and will only open it to 468 x 546. This cuts
out nearly 1 1/2 inches of printable area from my page.

This never happened in 2.3.1, but the windowBoundingRect was not a feature
there. So this is no bug. But it is annoying.

I have found a workaround, although it is not always consistent yet.

lock messages
open stack "Letter"
set the height of stack "Letter" to 648
print card 1 of stack "Letter"
close stack "Letter"

Scott, I know you meant well. But is there any chance of making this
property optional? Say, setting the windowBoundingRect to empty turns it
off, or something? I'm afraid that others will find they are not getting all
of their printouts as well.

Thanks,

Raymond

------------------------------

Date: Sun, 22 Oct 2000 01:25:43 -0600
From: Craig Spooner <[EMAIL PROTECTED]>
Subject: resfile/binfile ?

Greetings,

I've been trying to get MC to copy Mac resource info using "resfile" 
but I keep getting a "file not found" error.  From the list archive I 
found several examples of the proper syntax, but I can't get them to 
work.  For example, I'm using:

        put url ("resfile:" & tFileSource) into url ("resfile:" & tFileDest)

where tFileSource and tFileDest contain the complete paths and 
filenames.  I've also tried:

        put url ("resfile:" & tFileSource) into tSource
        put tSource into url ("resfile:" & tFileDest)

but with the same result.  Note that both work fine when "binfile" is 
used instead of "resfile."  Can anyone tell me what I'm doing wrong? 
I'm using 2.3.1 build 7.

Thanks,

Craig

------------------------------

Date: Sun, 22 Oct 2000 17:23:41 +0100
From: Kevin Miller <[EMAIL PROTECTED]>
Subject: Re: List enquiries

On 21/10/00 4:09 pm, "Blair Moxon" <[EMAIL PROTECTED]> wrote:

> Sorry if this is off topic but I haven't received any posts for three days.
> If I receive this post it will assure me that the list server is still
> running, and I haven't descended into another MS Outlook configuration
> nightmare!! (its great when it works - honest!)

There does appear to be an intermittant problem with this list delivering
individual messages to some of its recipients - we don't as yet know what is
causing this but are working on it.

> Could we re-institute the information footer at the bottom of the mail
> postings that identifies:
> 
> This is the MetaCard mailing list.
> Archives: http://www.mail-archive.......
> Info: http://www.xworlds.com/metacard.....
> Please send any bug reports to <[EMAIL PROTECTED]>, not this list.

We'll probably replace the software that we're using to run the list
shortly.  But the addresses won't change so it at most there should be a
minor glitch.  I'll keep people posted - Majordomo doesn't appear to be a
very good solution to our needs.

Regards,

Kevin

Kevin Miller <[EMAIL PROTECTED]> <http://www.runrev.com/>
Runtime Revolution Limited (formerly Cross Worlds Computing).
Tel: +44 (0)131 672 2909.  Fax: +44 (0)1639 830 707.

------------------------------

End of MetaCard List Digest V4 #16
**********************************

Reply via email to