image sizing (was "dump newbie image questiosn"(

Jon jbondy at sover.net
Mon Jun 6 07:33:58 EDT 2005


Nick, Jaque:

Here's a specific example.

I'm writing a music player.  The top 300 pixels of the window/stack (no 
matter how the user resizes the stack) is reserved for some fixed 
buttons and tables.  The remaining height, for the full width of the 
stack, is reserved for display of guitar tablature.  If the user wants 
to see more/better tablature, the user makes the stack taller.

In Delphi and windows, I specify an Image object/component that lives 
below the fixed objects, and automatically expands to fill all available 
space below the fixed objects. In Windows this is called Client 
Alignment.  When I put an image (data) into that Image (object), because 
of properties I set at design time, the image automatically becomes as 
large as possible, but without distorting, within the original bounds of 
the Image.  If there needs to be white space to the right or below the 
image, but within the Image, it is all done for me.

In Rev, I'm not sure how to get the Image to live below the fixed 
objects.  I guess I make a huge super-group out of all of that stuff, 
and then have the Image float below the group using Geometry.  I then 
have to inspect the incoming image and change the size of the Image to 
avoid the distortion.  Having every programmer intervene in this way is 
more complex and more prone to error.  And what I'm trying to do is such 
an obviously desirable behavior: that's why I'm frustrated.  I expect to 
roll my own in special circumstances, but the whole point of Rev is that 
it is powerful, right?  Not in this situation.  And not when it comes to 
Tables. Or processing image pixels.  Very primitive and slow.

In fact, my player is more complex than described above.  There are 
quite a few "panels" of objects that must move around depending on a 
variety of things (like "are we playing audio or video", because in the 
latter case, I have to provide screen real estate for the image; and 
"are the tablature files present", because I then have to provide space 
for those images).  I'm about to start struggling with how to do this in 
Rev.  The Geometry paradigm is very different than the Align paradigm on 
Windows/Delphi.  Not worse or better, that I can see, but different.  
And having had the IDE crash when I combined Geometry with On ReSize, 
I'm gun-shy.

I've read about how people use multiple cards stacked behind each other, 
with each card having virtually identical content.  I suppose I could 
try to design two or three fixed format cards and stack them, but I'm 
not familiar with the tradeoffs.  In Delphi I would NEVER duplicate 
objects, for fear that they would not synchronize with each other 
without my manual intervention.  How do I put a Table on three cards and 
have it appear the same on all cards (content if not size and position)?

For example, I gather that the Tab object does not work at ALL like in 
Windows, where each tab has different content.  I gather the Tab in Rev 
just gives the user a signal that a different card is desired, and 
provides the tab visual.  It is up to the user to put the varying 
content on every card (along with a series of redundant Tabs) and switch 
between cards manually (again, something that is not required in 
Delphi/Windows).  Many of you keep saying how easy Rev is to use, how 
powerful, how productive.  There are many counter examples, and Tabs 
seem to be one.

:)

Jon

Nicolas Cueto wrote:

>Hello.
>
>Sorry to barge in what seems like a private conversation
>between Jon and Jacqueline about lockLoc and image 
>resizing but it's reminding me of a similar "problem" I had 
>with one of my image-based stacks a long time back.
>
>Once upon a time, while my young EFL learners and I were 
>happily studying the English names of shapes using a 
>concentration game stack, I was very surprised to hear
>the word "rectangle" emitting from the PC speakers when
>the image on-screen was very much a "square". 
>
>Looking for the source of this mistake later on, I discovered 
>that the culprit was the lockLoc setting of each image object,
>Though the original image had indeed been a "rectangle", 
>the lockLoc of the image object forced the "rectangle" to fill 
>in the entire image object -- or, as Jon wrote, it scaled in both 
>directions.
>
>My solution then was to create a new rectangle image
>file, with lots of white space at the top and bottom of
>the rectangle.
>
>But something Jacqueline wrote to Jon is making
>me think that maybe there's another (easier!) way, 
>i.e.:
>
>  
>
>>Well, generally we calculate the dimensions before we set the image 
>>size. ;) Then it works okay.
>>    
>>
>
>"Calculate the dimensions"? Can someone explain how to do this
>with RunRev? (Or is Jacqueline just joking? ;) )
>
>Cause I have to agree with Jon that, at least sometimes, 
>the image object's lockLoc property does cause an ugly
>distortion of an original image file's size. 
>
>So, if there's a way around this "ugliness" ...
>
>Thanks.
>
>Cheers,
>Nicolas Cueto
>niconiko language school
>(J)
>
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>  
>


More information about the use-livecode mailing list