Create a button's icon with a part of a big image? - Beleaguered Castle

[richmond62]

I am very glad, Zak, that someone can help
you with the GM, because I cannot.

[Zax]

Personally I have found it almost impossible to use, that is why I'd far rather "roll my own."

I also never find a way to use the GM so I usually prefer to write my own script to change objects size and position on resizeStack handler.
My actual problem is that I have 52 SVG picts to move and resize. The operation takes so long it reminds me of an old 68k Mac

[stam]

My actual problem is that I have 52 SVG picts to move and resize. The operation takes so long it reminds me of an old 68k Mac

With so many objects I would probably not use the GM for all of these as there are pitfalls and it would be super-tedious. It may be possible to do this with the new responsive layout, but I really can’t get that to work yet…

If you number the cards sequentially (don’t use actual numbers, but something like card1, card2 etc) you can easily construct code to position and resize all cards relative to an anchor card in the on resizeStack handler (well, relatively easily anyway!). How you resize the anchor card is up to you, whether by GM or not is not the difficult bit.

If you mean the resizing & repositioning of your cards is slow, perhaps post your code here as others. May be able to help you optimise it.

[Zax]

To be more accurate, I encounter 2 problems:

1 - automatic resize
When a column contains more than a certain amount of cards, the entire board must be reduced, in order to have enough space to place other cards at the bottom of this column.

2 - manual resize : when the user resize the stack's window.
This event is obviously handled with resizeStack

In both case, I have to calculate the new position of the columns top card and loop over all cards to change their height, width and location.
This loop is very simple, it's something like:

Code: Select all

put item row of BCA_CARDS[col] into cardName // BCA_CARDS is a global containing all the cards name
set the height of img cardName to gArrDimsCard["height"]
set the width of img cardName to gArrDimsCard["width"]
set topLeft of img cardName to (coordH & "," & coordV)
add offsetPx to coordV

And yes, the resizing and repositioning of the cards is slow on my old machine.

In the case#2, when the user resize the stack's window, is there a way to lock the screen, or the process, in order to not trigger the resizing and repositioning until the user releases the mouse? With resizeStack, the resizing is a live process (which is very cool in most of the cases) but it's awful in my case

[richmond62]

There is nothing stopping you moving the resizeStack code to
inside a mouseUp.

BUT, there will be no continuous resizing.

[bn]

Hi Zax,

put item row of BCA_CARDS[col] into cardName // BCA_CARDS is a global containing all the cards name
set the height of img cardName to gArrDimsCard["height"]
set the width of img cardName to gArrDimsCard["width"]
set topLeft of img cardName to (coordH & "," & coordV)
add offsetPx to coordV

Could you try to define the final rect of the resized card in code and set the image cardName to that rect instead of setting height, setting width and setting topLeft. It should reduce the time a bit because LC does not have to recalculate the image as often. And I assume that you have a lockscreen/unlock screen wrapper for your resizing.

Kind regards
Bernd

[bn]

Hi Zax,

as far a resizing after the final resize is concerned the only hack I came up with is to test for "the mouse is not down" as shown in this small example stack

EDIT: the uploaded stack in this post is changed after I found a flaw in it. Please use this version.

resizeAfter Mouse is up II.livecode.zip

(1.39 KiB) Downloaded 70 times

Kind regards
Bernd

[richmond62]

Are you wanting to resize your game:

1. So it fits the screens of phones & tablets?

2. So that users on computers can do daft things?

If #1 the place to put the code is in an openStack command.

[Zax]

Great x2 Bernd

My original resize cards script took 1800 ms
When using rectangle, 910 ms
And finally, with lock screen, 95 ms!

Also, you example stack is perfect.
richmond, I don't understand when you say "there will be no continuous resizing". If I don't use Bernd's trick, resizing is continuous until the mouse is up.

[richmond62]

I meant there would not be continuous resizing if you removed your resize script from inside a mouseMove command and placed it inside a mouseUp command.

lockScreen is going to speed things up as the computer is not going to have to pump out continuous screen redraws.

[Zax]

I meant there would not be continuous resizing if you removed your resize script from inside a mouseMove command and placed it inside a mouseUp command.

OK, maybe I wasn't very accurate. I was talking about the built-in resize ability: when a stack is resizable and the user resizes the stack's window by dragging the bottomRight corner of the window.
Anyhow, all is working fine now (I'm now working on the history and saved games... more questions to come soon ).

[bn]

Hello all,

Please be aware that the 'Resize after Mouse is up" stack I posted in this thread has a flaw that made it send too many messages after resize stopped.

Here is a version that sends only one message after manually resizing a stack.

resizeAfter Mouse is up II.livecode.zip

(1.39 KiB) Downloaded 80 times

Kind regards
Bernd

[Zax]

Thanks Bernd for this fix.

I also tried with lock messages and it seems OK, though in my script, pNewWidth and pNewHeight values seems wrong to calculate the new dimensions of controls.

Code: Select all

on resizeStack pNewWidth, pNewHeight, pOldWidth, pOldHeight
   lock messages
   send "resizeControls pNewWidth, pNewHeight" to me in 1 milliseconds
end resizeStack

on resizeControls pNewWidth, pNewHeight
// pNewWidth, pNewHeight --> wrong values ???
   beep
   put 10 into tMargins
   put tMargins & comma & the bottom of btn "BtnReset" + tMargins & comma & the width of this stack - tMargins & comma & the height of this stack - tMargins into tRect
   set the rect of fld 1 to tRect
end resizeControls

resizeAfter Mouse is up III.livecode.zip

(1.87 KiB) Downloaded 69 times

[bn]

Hi Zax,

That is interesting. Apparently your "lock messages" kicks in after the first round of "resizeStack" and is only sent once at the first round. And it is only sent after the last "resizeStack" finished.
You can see this if you change in "resizeStack"

Code: Select all

send "resizeControls pNewWidth, pNewHeight, pOldWidth, pOldHeight" to me in 1 milliseconds

and in "resizeControls"

Code: Select all

on resizeControls pNewWidth, pNewHeight, pOldWidth, pOldHeight
   put "resizeControls --> new :" && pNewWidth && "x" && pNewHeight & " Old: " & pOldWidth && "x" && pOldHeight & "( stack :" && the width of this stack && "x" && \
         the height of this stack && ")" & cr after fld 1 /////

This behavior is atypical because in "normal" LC handlers if you lock messages send in time is sent anyways, apparently not within "resizeStack"

For me the "resizeStack" message is a strange message because it used to be that you could easily crash LC if you did something "resizeStack" did not like.
Mark Waddingham fixed at some point those crashes but "resizeStack" is still a bit different from normal messages.

If you add a "unlock messages" at the end of the "resizeStack" handler you get the "resizeControls" on every "resizeStack" event but also after the last "resizeStack" has ended.

In short: I would not use your solution because I am superstitious and I consider it an "off-label" use and the behavior might change without notice. I recomment you stick to the convoluted solution I propose which is in line of what you can expect.
(Unless Mark Waddingham sanctions your solution)

Kind regards
Bernd

[richmond62]

'Off-line', 'In-line', somewhere kinky wiggling off into the dark recesses of a forest . . .

. . . personally, if it works, and you annotate it adequately
so you have chance of understanding it in 10-15 years time
when you need to modify it, whether 1, 2 or 3 should not really matter.