Jim Hurley writes:
[snip]
I have a small addendum to the Storing Images discussion.
This is a variation on that method which is just a little simpler (it
doesn't require a closeCard handler) and produces a nice border around the image by simultaneously resizing the button.
Jim
Message: 1
Date: Sun, 9 Feb 2003 19:21:13 -1000
Subject: Re: Storing images
From: Sannyasin Sivakatirswami [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
On Sunday, February 9, 2003, at 01:25 PM, Jim Hurley wrote:
put the imageSize of image theImage into theImageSize
Someone wrote:
Put image 3 into image 4
This does not work for me. I tried both with images pointing to an
image stored elsewhere (outside of rev) and for images stored in the
stack. All I get is a white or gray image. What am I doing wrong? (Mac
OS 10.15)
Sannyassin wrote:
When leaving
On Montag, Feb 10, 2003, at 19:23 Europe/Zurich, mark mitchell wrote:
Someone wrote:
Put image 3 into image 4
This does not work for me. I tried both with images pointing to an
image stored elsewhere (outside of rev) and for images stored in the
stack. All I get is a white or gray image.
Jim Hurley wrote:
And just so all this info is in one place I will repeat the primary
utility used in the stack script of the substack
on resizeImage theImage,theRatio
--Reset the image size on the substack card to the desired size
set the defaultStack to imagesSubstack
put the
Sannyasin Sivakatirswami wrote:
Ha! Fantastic... what a great support group we have here! ;-)
On Monday, February 10, 2003, at 07:46 AM, J. Landman Gay wrote:
Actually, it isn't even necessary to store the original image size in
a custom property. Rev will automatically save the size so
I have a small addendum to the Storing Images discussion. If you wish
to have icons of a given image displayed with varying sizes on
different cards, there was a way of doing this suggested by Sannyasin
Sivakatirswami. In his method all images are stored once in a
substack. Those images
On Sunday, February 9, 2003, at 03:25 PM, Jim Hurley wrote:
I have a small addendum to the Storing Images discussion. If you wish
to have icons of a given image displayed with varying sizes on
different cards, there was a way of doing this suggested by Sannyasin
Sivakatirswami. In his method all
Bjoernke,
Nice post. The best way to reference an image-object to another imageobject
is to use the filename property. Then you need store the image only once (on
disk) and can reference it multiple times.
Those of you Mac HC users are used to doing this in the resource fork.
You'll need to
:42 AM
Subject: Re: Storing images
This thread confuses me, so I made some experiments, to clarify all
this for me, I will list the results of them here (if this is useful
for any of you then that is your own fault!):
setting the icon:
set the icon of button foo to image bar
Recently, Jim Hurley wrote:
A more elegant or less cumbersome solution (and idiot proof for the
end user) would be to embed the single images in some secret place
from which they might be referenced and a different size and
location for the image could be locked on each card.
Again,
--- Wolfgang M. Bereuter
[EMAIL PROTECTED] wrote:
any benefit of importing the image files?
for example what I use it for: a stack
structure where stacks can
easily be changed (updated) even from
unexperienced users without
thinking in the file path...
or change the whole app from
Software
Email: [EMAIL PROTECTED]
Web Site: http://www.sonsothunder.com/
- Original Message -
From: Scott Rossi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:14 PM
Subject: Re: Storing images
Recently, Jim Hurley wrote:
A more elegant or less cumbersome
Ken Ray wrote:
Only one comment I'd make, and that is that:
set the imageData of image 1 to the imageData of image 2
requires both images to have the same width and height, whereas:
put image 1 into image 2
causes image 2 to resize to fit the size of image 1 automatically.
Great tip
Maybe i am missing something about what you are trying to do... and
maybe this option you already know...
anyway, to add yet another option which works perfectly, does not
require that you reference images files from disk, allows for dynamic
resizing of all images on the fly, displays all
On Dienstag, Februar 4, 2003, at 01:10 Uhr, erik hansen wrote:
any benefit of importing the image files?
for example what I use it for: a stack structure where stacks can
easily be changed (updated) even from unexperienced users without
thinking in the file path...
or change the whole app
Jim Hurley wrote:
Perhaps inelegant isn't the word, but it can be cumbersome to set
the button icon to the image if you want to use different sizes on
different card. You need a preOpenCard handler on each card on which
the image appears in order to set the size of the image on that card.
This thread confuses me, so I made some experiments, to clarify all
this for me, I will list the results of them here (if this is useful
for any of you then that is your own fault!):
setting the icon:
set the icon of button foo to image bar
this will reference the exact same picture (same
At 6:42 pm +0100 5/2/03, Björnke von Gierke wrote:
This thread confuses me, so I made some experiments, to clarify all
this for me, I will list the results of them here (if this is useful
for any of you then that is your own fault!):
:)
lots of useful information snipped
I found no way to
Isn't there another issue regarding where images are stored? My
knowledge here is admittedly weak but I have had problems in the
past in referencing images stored on disk. To find the image a path,
either absolute of relative (relative to the current default folder)
needs to be given. If, in
--- Jim Hurley [EMAIL PROTECTED] wrote:
Isn't there another issue regarding where images are
stored? My
knowledge here is admittedly weak but I have had
problems in the
past in referencing images stored on disk. To find
the image a path,
either absolute of relative (relative to the
Judy wrote:
Yes, there are many different ways of doing one thing; problem is, it
doesn't matter if they're all equally inelegant/non-intuitive.
Maybe it's the non-assembly code programmer in me, but it's just not
clear
why, once you've embedded something, you have to re-embed it with each
Recently, Jim Hurley wrote:
Isn't there another issue regarding where images are stored? My
knowledge here is admittedly weak but I have had problems in the
past in referencing images stored on disk. To find the image a path,
either absolute of relative (relative to the current default
Judy Perry [EMAIL PROTECTED] wrote:
Maybe it's the non-assembly code programmer in me, but it's just not clear
why, once you've embedded something, you have to re-embed it with each
usage. This is just nuts. This results in bloatware.
I think there's some confusion -- you don't have to embed
**
Date: Wed, 5 Feb 2003 01:51:49 +0900
Subject: Re: storing images
From: mark mitchell [EMAIL PROTECTED]
I finally understand this thread. I couldn't figure out how set the
icon of button 1 to myImage could possibly be described as inelegant
(especially relative to HC's resource
Perhaps my gripe stems (as usual) from a lack of understanding. I've
tried something like this -- importing as a control some image. But I
didn't want it on the card where I imported it (not thinking about where I
was; okay, it wasn't really me it was a student) and so I clicked on it
and hit
J. Landman Gay writes:
There is no duplication of the image graphic when you do this; Rev just
inserts a temporary copy of the image into RAM just as addcolor does when
it draws the image to screen.
===
Is a copy of the image placed into RAM, or is there just a pointer created
that
I finally understand this thread. I couldn't figure out how set the
icon of button 1 to myImage could possibly be described as inelegant
(especially relative to HC's resource fork and pict external).
Perhaps inelegant isn't the word, but it can be cumbersome to set
the button icon to the
Recently, [EMAIL PROTECTED] wrote:
There is no duplication of the image graphic when you do this; Rev just
inserts a temporary copy of the image into RAM just as addcolor does when
it draws the image to screen.
Is a copy of the image placed into RAM, or is there just a pointer created
that
Judy,
Don't know about HC, but in RR when you delete the imageit's gone.
-Chipp
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Judy Perry
Sent: Tuesday, February 04, 2003 1:35 PM
To: [EMAIL PROTECTED]
Subject: Re: Storing images
Perhaps my
*embedded* into the stacks; if you don't, you can leave them on disk
and reference them as many times
I understand that the resource fork thing was very MacClassic oriented.
Still, one wonders why there isn't a ca 1987 elegant, modern solution
in
2003. [..] why, once you've embedded something,
What is the difference between storing it in a resource fork and
storing it in a substack, or as an image in a group that can be placed
on any card. Both the latter do not add any more data to the
stack...there is only one copy of the imagedata in the stack even
though it appears in multiple
Would it be possible to embed the image on one card (like
a PICT resource or whatnot), and then reference that image other places
in the stack (to avoid re-embedding bloat)?
Hi Jim
Using a PICT resource is how you do it HyperCard. In Rev there is an image
control. The image data that the
I think that what I really need is a 12-step program for recovering
resource fork-aholics...
;-)
Judy
On Tue, 4 Feb 2003, Sannyasin Sivakatirswami wrote:
What is the difference between storing it in a resource fork and
storing it in a substack, or as an image in a group that can be placed
I think I recall a tip on this list some time ago on reducing file size.
I have an image which is used on more than one card. Rather than
import the image as a control to each card separately, is there a
single place within the stack from which it might be called as
reference to each card? I
Hi Jim,
you can import the image once, then create a button on each card as a
placeholder for that image and set the buttons icon property to the ID of
the image you have imported.
Or you can create a group containing your image and set it´s
backgroundBehavior to true.
Hope that helps,
Malte
Jim Hurley wrote:
I think I recall a tip on this list some time ago on reducing file size.
I have an image which is used on more than one card. Rather than
import the image as a control to each card separately, is there a
single place within the stack from which it might be called as
reference to
Wow! What an inelegant solution. Is there some technical reason it has
to be that way? Even though it involved the use of the dreaded resource
fork, the Hypercard way of importing such things as images, sounds and the
like ONCE and then being able to intuitively (as far as addColor anything
was
, 2003 1:41 PM
Subject: Re: Storing images
Wow! What an inelegant solution. Is there some technical reason it has
to be that way? Even though it involved the use of the dreaded resource
fork, the Hypercard way of importing such things as images, sounds and the
like ONCE and then being able
--- Ken Ray [EMAIL PROTECTED] wrote:
Now the inelegant solution is
only true if you want the images *embedded*
into the stacks; if you don't,
you can leave them on disk and reference
them...
did anyone ever benchmark the difference btw the
two approaches?
=
[EMAIL PROTECTED]
Recently, erik hansen wrote:
Now the inelegant solution is
only true if you want the images *embedded*
into the stacks; if you don't,
you can leave them on disk and reference
them...
did anyone ever benchmark the difference btw the
two approaches?
There's no foolproof way to benchmark
--- Scott Rossi [EMAIL PROTECTED] wrote:
The benefit of referencing external files is
ease of file management (you
add and remove images from an external 'images'
directory at will), and
potentially lower memory requirements, if you
reference the images only when needed.
any benefit of
Recently, erik hansen wrote:
The benefit of referencing external files is
ease of file management (you
add and remove images from an external 'images'
directory at will), and
potentially lower memory requirements, if you
reference the images only when needed.
any benefit of importing
--- Scott Rossi [EMAIL PROTECTED] wrote:
Recently, erik hansen wrote:
The benefit of referencing external files is
ease of file management (you
add and remove images from an external
'images'
directory at will), and
potentially lower memory requirements, if
you
reference the
I'll chime in here for the Rev way of doing it, if you intend to use
images in multiple instances and even more... if you want to use those
same images at different sizes in different instances...
Having used the store image in a substack, call via button icon image
ID method... I would
Ken,
I understand that the resource fork thing was very MacClassic oriented.
Still, one wonders why there isn't a ca 1987 elegant, modern solution in
2003.
Yes, there are many different ways of doing one thing; problem is, it
doesn't matter if they're all equally inelegant/non-intuitive.
Maybe
46 matches
Mail list logo
