I woke up with a "dream" saying ..."hmmm maybe it just a timing issue;
stay away from "preopen[anything]
At least in my case, this worked out of box, super simple
9 line of code to get initial placement
12 line of code in my resize handler
!
So long as
a) the card is rendered
b) all other open
@Brian
That was interesting an experiment.
I reduced all geometry to this
*on*openCard
*put*mobileRectGet() intotStackRect
#mobileRectSet get the screenrect on app init
*if* isMobile() *then*
*if* theplatformisandroid *then*
*set*therectofwidget"body"to0,0,486,765
I still think you are working too hard. I just put this on my Fire. (I
had to manually code the FSM). This short handler sets everything properly:
on fixBackground
local tCardW, tScreenW, tScreenH, tNewH, tRect
put the width of this card into tCardW
put the effective working screenRect
> Le 30 août 2018 à 20:44, Ludovic THEBAULT via use-livecode
> a écrit :
>
> You can download my test stack here :
> https://www.dropbox.com/s/iwwm2syiqzqamtg/testsubstack2.livecode?dl=1
>
> Note : my script doesn’t work properly : i tested it on an android tablet and
> the result is not accu
> Le 30 août 2018 à 17:14, Sannyasin Brahmanathaswami via use-livecode
> a écrit :
>
> Ludovic
>
> Can you copy that whole handler to the list?
>
> round((item 4 of the screenrect*the systemscale)/2)-theight // +theight
>
> only seems partial?
Hello,
You can download my test stack here :
ices
> rdim...@evergreeninfo.net
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
> Behalf
> Of Sannyasin Brahmanathaswami via use-livecode
> Sent: Thursday, August 30, 2018 10:16 AM
> To: How to use LiveCode
> Cc: Sannyasin B
rdim...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Sannyasin Brahmanathaswami via use-livecode
Sent: Thursday, August 30, 2018 10:16 AM
To: How to use LiveCode
Cc: Sannyasin Brahmanathaswami
Subject: Re: fullscreenmode and rect
I tried it.
Sure, I get the screenrect in advance; I put an answer sRect in a one stack
opencard script...
I get an answer...
but this does not work on the stack the has browser...
so I now suspect to browser widget is blocking "registration" the screen rect.
Now only that it may be block
Ludovic
Can you copy that whole handler to the list?
round((item 4 of the screenrect*the systemscale)/2)-theight // +theight
only seems partial?
On 8/19/18 6:11 PM, Ludovic THEBAULT via use-livecode wrote:
> But i found i can get the « real » top and bottom with : round((item 4 of the
> scree
Ha! One has to thank our community for "never giving up!" That spirit alone is
worth it weight in gold -- the Indy License!
@ Brain "Gee, why didn't I think of that!"
Not calling as substack; I use this as navigation between mainstack (the splash
screen and that has the stack files is always
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net
-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Sannyasin Brahmanathaswami via use-livecode
Sent: Wednesday, August 29, 2018 3:38 PM
To: How to use LiveCode
Cc: Sannyasin Brahmanath
Aren't you calling this as a sub-stack? If so, could you capture the
screen rect before the switch and pass in the data or cache to the file
system and read it in?
On Wed, Aug 29, 2018 at 2:39 PM Sannyasin Brahmanathaswami via use-livecode
wrote:
> @Hugh
>
> quick update
>
> your code worked; b
@Hugh
quick update
your code worked; but only after turning the phone (resize handler sent)
but on preopenstack, preopencard, or opencard
setupStackRect
fails, because the screenRect is not registered yet (my guess, might be
something else)
https://quality.livecode.com/show_bug.cgi?id=21538
It's more complicated than that. Using the iPad Air simulator and this
preOpenCard handler:
on preopenstack
mobileSetAllowedOrientations("portrait")
iphoneUseDeviceResolution true,true
end preopenstack
When I press the "Get the rect" button it reports the stack, card, and
screenrect are al
H
So it reports that the stack and screen are 768/1024 yet does not fill the
screen? That is very odd. For me it did fill the screen until I changed it to
be short on purpose.
And yes, the sim is pretty fast once it boots.
Thanks,
Brian
On Aug 24, 2018, 4:26 PM -0500, J. Landman Gay via use
That's the deal though...it shouldn't need to resize at all, but in the
simulator it doesn't fill the screen. The XCode simulators are really
fast though. If you ever do get into Android, avoid their emulator, it's
dog slow.
This thread is approaching cheese dimensions. I hope non-interested
I was just able to test in the iPad Air. It does not need to resize
though. In order to do an effective test, I shrank the stack by 100 px
(just moved all the stuff at the bottom up that much and shortened the
stack height).
At that point, if I included my "fixBackground" handler in the
(pre)ope
I never even try the sim. I’ll give it a try this weekend though.
None of the regular iPads should require a resize. Only the pro models have a
different rect.
Thanks,
Brian
On Aug 24, 2018, 2:39 PM -0500, J. Landman Gay via use-livecode
, wrote:
> On 8/23/18 8:30 PM, Brian Milby via use-livecod
On 8/23/18 8:30 PM, Brian Milby via use-livecode wrote:
The original stack worked fine on my iPad (since it was sized at the same
resolution).
Maybe I chose the wrong simulator, but on an iPad Air it failed to
resize correctly with or without FSM. I looked up the screenrect and it
claimed to
I caught typo.
I get it to work on iOS but not an Android, so I have a ticket to support and
that.
in an app, there is a lot change from on stack another, I frequently have add
time from Android to keep up (never on iOS)
This is so straight forward, I have to assume there is bug (just a quess
First, I think you have a typo where "/25" should be "-25"...
set loc group "footer" to ( (item 2 of tRect)/2,(item 4 of tRect)/25 ) #
Typo: -25
Second, for safety, ensure integer values...
set loc group "footer" to round((item 2 of tRect)/2), (item 4 of tRect)-25
Third, if still not working
@ Sannyasin Brahmanathaswami
I was finally able to take some time and load the _r9 version of your demo
stack. When initially loaded, the image did fill the browser window, but
when I pressed the play button it did not take over the entire screen.
When I rotated, it did resize as expected. I'm n
@Ludovic / @Jacque
If you are just wanting a background to cover the extra space, why not just
make it oversized and not worry about adjusting it?
The original stack worked fine on my iPad (since it was sized at the same
resolution). I made it a substack of another one and used a button to "go
s
On 8/23/18 12:59 AM, Ludovic THEBAULT via use-livecode wrote:
Le 22 août 2018 à 22:24, J. Landman Gay via use-livecode
a écrit :
On 8/22/18 3:13 PM, J. Landman Gay via use-livecode wrote:
But the stack should still fill the screen and it doesn't.
This will resize the stack the same way as
This thread will never finish (hehe)
I am still have trouble getting the two object in the stack in place when we
open stack on mobile.
The resize handlers wrok, and soon as we rotate the phone and back and geometry
is implemented.
But not on open stack..
So I use your script. I was not orie
Coming in late to the thread, but would this not work on all platforms?
on preOpenStack
setupStackRect
end preOpenStack
on orientationChanged
-- setupStackRect
end orientationChanged
on setupStackRect pWidth,pHeight
if pWidth="" and pHeight="" then
put the effective working screenRect
> Le 22 août 2018 à 22:24, J. Landman Gay via use-livecode
> a écrit :
>
> On 8/22/18 3:13 PM, J. Landman Gay via use-livecode wrote:
>> But the stack should still fill the screen and it doesn't.
>
> This will resize the stack the same way as your "adapt" handler does, so you
> can eliminate
On 8/22/18 3:13 PM, J. Landman Gay via use-livecode wrote:
But the stack should still fill the screen and it doesn't.
This will resize the stack the same way as your "adapt" handler does, so
you can eliminate that entirely:
on preopenstack
mobileSetAllowedOrientations("portrait")
iphoneU
On 8/21/18 2:11 PM, Ludovic THEBAULT via use-livecode wrote:
But even « the rect of this cd » return the rect of the stack i created
(0,0,768,1024) not the rect of the screen.
I’ve made a test stack. It’s an « iPad » stack. Test it with iOS simulator on
an iPhone device.
https://www.dropbox.co
Brian Milby wrote:
> Richard wrote:
>> ...another useful detail when placing things within groups under
>> most circumstances is to set the lockLoc of the group and everything
>> within it. So much becomes so simple that way, and without it the
>> automatic accommodate of interior objects within
@Richard, could you elaborate on the lockLoc? I assume you are talking
about the part where the group will not resize based on control positions
within and that if you set H/W of a control the topLeft remains the same
along with images not resizing back to their source's size. Did I miss
anything
Winner gets to eat the worm!
Bob S
> On Aug 21, 2018, at 13:43 , Richard Gaskin via use-livecode
> wrote:
>
> J. Landman Gay wrote:
>
> > But yeah, maybe you and I could team up and do a one-on-one debate.
> > Someone could set up a rope ring and we could wear boxing gloves. :)
>
> Given t
J. Landman Gay wrote:
> But yeah, maybe you and I could team up and do a one-on-one debate.
> Someone could set up a rope ring and we could wear boxing gloves. :)
Given that we've never disagreed on how to solve a specific resizing
problem, I would imagine it would be the most boring debate eve
Sannyasin Brahmanathaswami wrote:
> @ Richard I did not ask to a "simple" example.
>
> "Just yesterday I delivered a UI with several hundred controls on a
> card, some quite deeply nested within groups. But the layout did not
> require writing anywhere close to one line per object. Some was
> h
I should step into middle this because our app is under discussion.
Jacque: I appreciate your support of LC amazing auto-resizing options.
They are truly marvelous
But perhaps we take a Big View of Landscape. You have to realize I done
web development since 1993. Currently we "evolving" two new w
On 8/21/18 10:28 AM, Sannyasin Brahmanathaswami via use-livecode wrote:
@ Monte:
"mobileSetFullScreenRectForOrientations to set the rects you want the stack to be
for each orientation"
you mean we can actually set up several of these with the same preopenstack
handler! That big news...
I th
On 8/21/18 1:26 PM, Richard Gaskin via use-livecode wrote:
Jim Lambert wrote:
> A shootout between FSM vs. scripted resizing might make a good LC
> Global presentation.
> The pros and cons of each. Cases where one may be better than the
> other. Etc.
> Examples.
I touched on it in my LCG t
> Le 20 août 2018 à 22:36, J. Landman Gay via use-livecode
> a écrit :
>
> On 8/19/18 11:11 PM, Ludovic THEBAULT via use-livecode wrote:
>> But i found i can get the « real » top and bottom with : round((item 4 of
>> the screenrect*the systemscale)/2)-theight // +theight (for the bottom)
>> wh
Jim Lambert wrote:
> A shootout between FSM vs. scripted resizing might make a good LC
> Global presentation.
> The pros and cons of each. Cases where one may be better than the
> other. Etc.
> Examples.
I touched on it in my LCG talk on UX in October last year.
It was only a brief part of the
Bob Sneidar wrote:
> I've said this before, and perhaps it bears repeating. Many apps do
> not support resizing simply because the nature of the app does not
> lend itself to it.
I think everyone here would agree with that.
When an app doesn't need to do something, don't do it.
While most apps
J. Landman Gay wrote:
> Auto-resizing does require an awareness during initial layout of how
> fullscreenMode works. The objections you've raised can all be dealt
> with if you're a stickler for HIG (which even the companies who
> publish them don't follow. They're just guidelines.)
Of course. B
skin via use-livecode
Sent: Tuesday, August 21, 2018 1:09 PM
To: use-livecode@lists.runrev.com
Cc: Richard Gaskin
Subject: Re: fullscreenmode and rect of a substack on mobile device ?
Monte Goulding wrote:
> Aha… yes a number of members of the team (myself included) have become >
> q
Monte Goulding wrote:
> Aha… yes a number of members of the team (myself included) have become
> quite familiar with the Siva Siva app. It has exposed/highlighted
> quite a number of accelerated rendering issues that we have fixed in
> 9.0.1.
Thanks, Monte. v9.0.1 is shaping up nicely, everythi
A shootout between FSM vs. scripted resizing might make a good LC Global
presentation.
The pros and cons of each. Cases where one may be better than the other. Etc.
Examples.
Jim Lambert
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please
Wonderful discussion!
@ Bob: agreed that "from ground up" could be one approach. But i have use cases
where fully response screen is need and uses case where FSM is the best
decision. it not "either" or "or" using resizestack of fullScreedMode
So the "tension" behind making that decision can t
I've said this before, and perhaps it bears repeating. Many apps do not support
resizing simply because the nature of the app does not lend itself to it. We
use an ERP called eAutomate. If you try to load the app on a monitor below a
minimum resolution, it bugs out and fails to display a detail
On 8/20/18 8:32 PM, Richard Gaskin via use-livecode wrote:
Swami has not asked me to evaluate strategies for precise control of his
layouts. That would not be possible until I see how things are
constructed.
He estimated months, and that sounds about right. Every card is laid out
differently
> On 21 Aug 2018, at 12:08 pm, Richard Gaskin via use-livecode
> wrote:
>
> I was referring to a post earlier in this thread which mentioned some
> additional support via email with the author from Panos and Eleanor.
Aha… yes a number of members of the team (myself included) have become quit
Monte Goulding wrote:
>> On 21 Aug 2018, at 11:32 am, Richard Gaskin wrote:
>>
>> - In this thread we have at least half a dozen people, including two
>> from the core team, all working together to explore various options
>> for placing one object within a resizing method chosen for its
>> ostens
> On 21 Aug 2018, at 11:32 am, Richard Gaskin via use-livecode
> wrote:
>
> - In this thread we have at least half a dozen people, including two from the
> core team, all working together to explore various options for placing one
> object within a resizing method chosen for its ostensible e
J. Landman Gay wrote:
> On 8/19/18 11:45 PM, Richard Gaskin via use-livecode wrote:
>> Consider a Note app. At the top is a navbar that spans the width of
>> the device at 60 px tall; below is a field for the user to type in;
>> centered below that is a "Save" button.
>>
>> This is in the card s
On 8/19/18 11:45 PM, Richard Gaskin via use-livecode wrote:
Consider a Note app. At the top is a navbar that spans the width of the
device at 60 px tall; below is a field for the user to type in; centered
below that is a "Save" button.
This is in the card script:
on resizeStack x,y
set th
On 8/19/18 11:11 PM, Ludovic THEBAULT via use-livecode wrote:
But i found i can get the « real » top and bottom with : round((item 4 of the
screenrect*the systemscale)/2)-theight // +theight (for the bottom)
where theight is the height of my stack before fullscreenmode.
You should be able to g
From: Brian Milby
To: How to use LiveCode
Subject: Re: fullscreenmode and rect of a substack on mobile device ?
Message-ID:
In the end, I guess I need to get an Android device so I can start testing.
My go-to source for Android test devices is the local grocery store so
I can buy a pre
@ Brian and Jacque
Thanks for digging to this. Panos write on QA and that line 14 (position
the group explicitly) in required.
The background is set "super wide" for that I was using FullScreenMode,
do that it would appear at the way across on iPad. Clearly set the
explicitly is required
@Brian,
Terry Judd wrote:
> On 20 Aug 2018, at 4:50 pm, Richard Gaskin wrote:
>>
>> Terry Judd wrote:
>>
>> > Yeah, I've used FSM in combination with scripting in the android
>> > versions a couple of apps (admittedly they were only designed to
>> > work in portrait mode) and it seemed to work well enoug
On 8/20/18 2:29 AM, Terry Judd via use-livecode wrote:
Oh, and my apps probably weren't terribly HIG compliant either. I used custom
buttons and controls that looked and functioned identically on Android and iOS
versions of the same app.
Ditto. I don't think I've ever had to work on a stack t
On 8/19/18 11:11 PM, Brian Milby via use-livecode wrote:
When the engine resizes the stack, I’m assuming that it takes into account any
system furniture? That isn’t a consideration for iOS (at least yet). I’m
excluding keyboard for the moment.
The screenrect is always the actual size of the s
On 20/08/2018 5:01 pm, "use-livecode on behalf of Terry Judd via use-livecode"
wrote:
On 20 Aug 2018, at 4:50 pm, Richard Gaskin via use-livecode
wrote:
>
> Terry Judd wrote:
>
> > Yeah, I've used FSM in combination with scripting in the android
> > versions a couple
On 20 Aug 2018, at 4:50 pm, Richard Gaskin via use-livecode
wrote:
>
> Terry Judd wrote:
>
> > Yeah, I've used FSM in combination with scripting in the android
> > versions a couple of apps (admittedly they were only designed to work
> > in portrait mode) and it seemed to work well enough.
>
>
Terry Judd wrote:
> Yeah, I've used FSM in combination with scripting in the android
> versions a couple of apps (admittedly they were only designed to work
> in portrait mode) and it seemed to work well enough.
If you make a button that looks HIG-savvy finger-sized on a 4" phone,
what happens
On 20/08/2018 2:45 pm, "use-livecode on behalf of Richard Gaskin via
use-livecode" wrote:
Most of the lengthier discussions I've seen about layout handling here
and on the forums stem from attempting to get precise control from FSM.
In some cases it may be possible to mix FSM with
Brahmanathaswami wrote:
> re Geometry: You keep telling us this again and again, but you never
> provide an example.
Given how many years most of the members of this list have been
scripting, it hadn't occurred to me that would be useful. Here's a
simple example that illustrates the basics, th
Brian Milby wrote:
> I can't speak directly to Android, but once you start doing resize
> handlers, I can't see using fullscreenmode. If you are going to
> position anything, may as well position it based on actual device
> metrics.
That's all I was getting at when I wrote:
"FullScreenMode makes
When the engine resizes the stack, I’m assuming that it takes into account any
system furniture? That isn’t a consideration for iOS (at least yet). I’m
excluding keyboard for the moment.
I’m not sure why there should be a difference between any platform though. Line
14 put the group’s center 25
> Le 18 août 2018 à 20:32, Richard Gaskin via use-livecode
> a écrit :
>
> Ludovic THEBAULT wrote:
>
> > How get the « real » rect of the stack ?
>
> Without fullScreenMode it's as simple as:
>
>get the rect of this stack
>
> FullScreenMode makes handling dynamic layout details complex.
On 8/19/18 10:21 PM, Brian Milby via use-livecode wrote:
I'm not sure what the fleet of widths would
need to be supported on the Android side though.
They vary all over the place. Basically you need to calculate a ratio
and set all the control sizes accordingly.
I can't speak directly to An
The stack is built for iPhone 6/7/8 Plus dimensions (414px wide). This
means that the navigation bar is a little too wide to show properly on a
regular iPhone 6/7/8. The icons are 384px wide (edge to edge) and those
phones are only 375px wide. If you also want to target the iPhone 4/5/5s
then th
On 8/19/18 9:37 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
"Intuitively" resize stack is all that is required.
And, "intuitively" a group should place all controls relative to itself.
And it does on iOS
I think that was just incidental. The original stack was sized to fit
the same
I was mistaken on the show/hide thing. The controls were behind the
browser the whole time.
On Sun, Aug 19, 2018 at 9:55 PM, Brian Milby wrote:
> Line 14 is required on iPad. Otherwise the controls stay where they
> originated (behind the browser). There is really no need to hide the icons
>
Line 14 is required on iPad. Otherwise the controls stay where they
originated (behind the browser). There is really no need to hide the icons
anyway though... they will be below the physical screen when in landscape
mode. That saves 2 lines :)
On Sun, Aug 19, 2018 at 9:49 PM, J. Landman Gay vi
Jacque wrote:
"I see. That looks like a redraw problem. The resizeStack handler
isworking but the redraw fails. I did notice the icons were missing but
didn't try to figure out why. A quick test says the footer is visible it
portrait and false in landscape, but it isn't being drawn to screen for
s
On Android, hiding and showing a group works as expected, I don't need to
loop through the controls to show them. At first I thought they weren't
being drawn, but in fact the whole group was below the bottom of the stack.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software
@Brian and all > glad this opened an important discussion..
and thank to the attempt to make it work @Brian footer control were too far
down on that card(android)
Many of cards in the SivaSiva app, would need major geometry refactoring
(month(s) of work) without fullScreenMode...so I am not con
> On 20 Aug 2018, at 10:53 am, Richard Gaskin via use-livecode
> wrote:
>
> As long as both messages are sent it may not matter, but that's the thing I'm
> unclear on: what does orientationChanged tell us on a mobile device that
> resizeStack doesn't? When is one sent without the other sent
Jacque wrote:
> Android does receive orientationChanged messages. I've been tinkering
> with Swami's test stack, and dynamic positioning (no fullscreenMode)
> works fine with some effort.
Is there a benefit to responding to orientationChanged instead of
resizeStack?
As long as both messages ar
I did figure out that within preOpenCard, the reported stack rect is still
the dimensions of the saved stack file (at least on iOS). There is also
the detail that when you hide a group, it sets all of the objects to hidden
which has to be undone in a loop. I've worked out moving the group and the
Android does receive orientationChanged messages. I've been tinkering
with Swami's test stack, and dynamic positioning (no fullscreenMode)
works fine with some effort.
The footer isn't a widget, it's a group containing half a dozen
controls, so they all need to be individually managed. You wer
You probably still want to set the rect for the footer to be sure it lands
where you want it on different size devices. That could be done in the
preOpenCard handler (just put it where it needs to be for portrait)
on preOpenCard
local tWidth, tHeight, tFooterRect
put the width of this stack
@Brian Milby
Something just clicked... if fullscreenmode is not empty, then resizestack
messages are not generated.
You are right! No "fillscreenmode" and 14 line of code works on iPhone.
But on not my Pixel.
--
# Geometry
on preOpenCard
resizeStack the width of thi
If you just want the controls to have the same relative position/size, then the
GM can handle this. If you want to change metrics based on portrait/landscape
then you either need to add PM or write a custom resize handler that takes
orientation into account. My code above should work for the fir
On 8/18/18 8:46 AM, Richard Gaskin via use-livecode wrote:
> With LC's logical pixels, have total control over our layouts to make
> optimal use of every precious pixel on small screens, all with no more
> work than we've already become accustomed to after years of scripting
> for resizable wind
@Sannyasin
Something just clicked... if fullscreenmode is not empty, then resizestack
messages are not generated. Which is part of why the new commands were
created. For what you want with the browser, your handlers should be very
simple. Here's what I came up with to put the browser widget and
On 8/18/18 7:52 PM, J. Landman Gay via use-livecode wrote:
Actually, the rect of the stack remains constant in fullscreenmode, you
don't need to account for the engine resizing. All placement
calculations can be done normally. That's one of the beauties of it.
I didn't express this exactly rig
Actually, the rect of the stack remains constant in fullscreenmode, you
don't need to account for the engine resizing. All placement calculations
can be done normally. That's one of the beauties of it.
Handling dynamic placement is no different than without fullscreenmode,
except that you don'
Here is the card script that I just tested on iOS. It will rotate a two
object card between portrait/landscape on my phone with no issues. It
handles either orientation as the initial orientation.
local sOrientation, sLongSide, sShortSide
on preOpenCard
local tScreenRect
if the environme
Ludovic THEBAULT wrote:
> I’ve a stack for phone and a substack for tablet (with iPad ratio,
> 1024*768). i use the fullscreenmode to « show all »
>
> On android tablet, the ratio height/width is sometimes very different
> from iPad.
> I tried to change the height of the substack before open it b
For your browser example, you probably want to use noScale. You just need to be
sure you capture the rect at the right time. You don’t know the new rect until
after the orientation changed handler ends. I’ll see if I can locate that stack
example again that you put up. Unfortunately I can only t
I have a similar issue with a stack that
a) contains a browser that wants to fill the entire screen (of any device)
b) a tool bar on the bottom, the background ( 50 px wide) which to set to 2000
wide
c) a 4 widget that appear on bottom on top to background.
It should work on portrait and landsca
you could try using either the working or effective adjectives before the
screenRect
working ScreenRect
effective screenRect
to see if you get better results?
from the dictionary
/Adding the working adjective to either form returns the virtual
co-ordinates of each screen's working-area. The wo
Hello,
I’ve a stack for phone and a substack for tablet (with iPad ratio, 1024*768).
i use the fullscreenmode to « show all »
On android tablet, the ratio height/width is sometimes very different from iPad.
I tried to change the height of the substack before open it but with no luck :
// in the
91 matches
Mail list logo
