Local files in browser widget
I think I asked this before but it isn't working now. I thought
specialFolderPath("resources") was okay for read-only files. It fails on
Android.
put specialFolderPath("resources") & "/tFolder/tFile.html" into tPath
set the url of widget "browser" to ("file://" & tPath)
I get an error that the file was not found. It's there, the folder was
included in the Copy Files pane in standalone settings. When I insert an
answer dialog to view the path, there's a string that ends with
"...base.apk/tFolder/tFile.html" so I think that's right.
Do I need more or fewer slashes?
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Elevating User Rights of Livecode on Linux
On 7/3/19 9:59 AM, Dalton Calford wrote: nevermind about the /. Just discovering '' vs "" usage. Still learning livecode and the cheat sheets are not as robust as I would prefer. Re that, I see bug #16941 has a status of "AWAITING_MERGE". https://quality.livecode.com/show_bug.cgi?id=16941 and references https://github.com/livecode/livecode/pull/5781 They've both been sitting in limbo for two years now. Has support for single-quotes been sidelined? Dropped? What does "AWAITING_MERGE" mean in this context? -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up (Sean Cole (Pi))
On 7/10/19 1:07 PM, Quentin Long via use-livecode wrote: One fictional contemplation of the 4th and 5th dimensions:https://johnesimpson.com/pdf/Ifth_of_oofth-waltertevis.pdf Heh. Thanks, Quentin. Walter Tevis' first published story! -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Accessibility
On 7/11/19 1:57 PM, Paul Dupuis via use-livecode wrote: On 7/11/2019 2:41 PM, J. Landman Gay via use-livecode wrote: Screen readers don't work in LC. How do those of you who support accessibility provide that? Is there anything in LC itself that supports the ADA act? This comes up repeatedly on this list. Any Desktop LC app is compatible with some OS accessibility tools, typically screen magnifies as they do not rely of any hooks in the App itself. Most all screen readers require in App API hooks. With widgets and FFI support, it might be possible now (LC9+) to create a library for one or more of the major screen readers There are also some OS provided screen reading tools that I have not tested with LC7, 8, or 9, but they did not work with LC6 as the UI controls (buttons and field primarily) were not OS standard controls, but LC specific. We get about 1-3 requests per year for screen reading support for our app. I'd love to provide support, but the cost (at least in the past) develop Externals and integration, if it even had been possible, would have bankrupted us. JAWS seems to be the most requested. If you look into the Widgets route and see any promise of a solution, please let me know. I wonder if the PDF widget would be compatible. Doesn't it use the OS API? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Best Practice with Player object to determine audio or video
Paul: > Is this an approach you have coded and used? Yes. If you had some code using your mediaType getprop, such as: if the mediaType of player 1 is "Video" then -- do something It could become, for example (a minimal change): if the mediaTypes of player 1 contains "Video" then -- do something Etc. Used successfully in familiar contexts. Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Best Practice with Player object to determine audio or video
Hi Paul, > Am 11.07.2019 um 21:02 schrieb Paul Dupuis via use-livecode > : > > the mediaTYpes property returns tracks (and the documentation doesn't say > whether the list is cr delimited or comma delimited, but that is a docs issue) > > Are you saying that for example if (the mediaTypes of player X contains > "audio" and not (the mediaTypes of player X contains "video")) is definitely > an audio only media file? and conversely if (the mediaTypes contains "video") > it is a video media file? > If not media file has been set for the player, what does "the mediaTypes" > return (once again, the documentation doesn't say!) > > Is this an approach you have coded and used? 10 seconds of testing revealed this: Filename not set -> mediatypes = EMPTY Loaded a video without sound Default video of LC -> video Loaded a video with sound MP4 -> video,audio Loaded a sound file MP3 -> audio I'll leave the conclusions to you! 8-) Best Klaus -- Klaus Major https://www.major-k.de kl...@major-k.de ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Best Practice with Player object to determine audio or video
the mediaTYpes property returns tracks (and the documentation doesn't say whether the list is cr delimited or comma delimited, but that is a docs issue) Are you saying that for example if (the mediaTypes of player X contains "audio" and not (the mediaTypes of player X contains "video")) is definitely an audio only media file? and conversely if (the mediaTypes contains "video") it is a video media file? If not media file has been set for the player, what does "the mediaTypes" return (once again, the documentation doesn't say!) Is this an approach you have coded and used? On 7/11/2019 1:32 PM, Curry Kenworthy via use-livecode wrote: Built-in "mediaTypes" property is pretty handy! Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Accessibility
On 7/11/2019 2:41 PM, J. Landman Gay via use-livecode wrote: Screen readers don't work in LC. How do those of you who support accessibility provide that? Is there anything in LC itself that supports the ADA act? This comes up repeatedly on this list. Any Desktop LC app is compatible with some OS accessibility tools, typically screen magnifies as they do not rely of any hooks in the App itself. Most all screen readers require in App API hooks. With widgets and FFI support, it might be possible now (LC9+) to create a library for one or more of the major screen readers There are also some OS provided screen reading tools that I have not tested with LC7, 8, or 9, but they did not work with LC6 as the UI controls (buttons and field primarily) were not OS standard controls, but LC specific. We get about 1-3 requests per year for screen reading support for our app. I'd love to provide support, but the cost (at least in the past) develop Externals and integration, if it even had been possible, would have bankrupted us. JAWS seems to be the most requested. If you look into the Widgets route and see any promise of a solution, please let me know. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Accessibility
Screen readers don't work in LC. How do those of you who support accessibility provide that? Is there anything in LC itself that supports the ADA act? -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Question about "the screen" property of stacks...
On 2019-07-11 19:30, Paul Dupuis via use-livecode wrote: Sorry, one more question: I assume since 'the screen of stack' is calculated dynamically, that in a 'on desktopChanged' handler (triggered by a monitor being removed) that looking at 'the screen of stack' for a stack on the now-removed monitor would give you the closest remaining monitor? Yes - the engine refetches the displays list (which you see in the C code) before desktopChanged is sent (indeed, the engine responds to an OS notification about the screen setup changing in order to send the message). Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up (Sean Cole (Pi))
Wonderful! [Massive-grin]. That pleases me a lot. Thank you for sharing it. :D Sean Cole Pi Digital Prod Ltd > On 11 Jul 2019, at 16:17, Bob Sneidar via use-livecode > wrote: > > Great story! > > Bob S > > >> On Jul 10, 2019, at 13:07 , Quentin Long via use-livecode >> wrote: >> >> sez Sean Cole (Pi):>I've just been teaching my youngest about the 4th - nth >> dimensions. Time is >>> not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are >>> Length, height and width then the 4th is depth, ie, going inwards and >>> outwards as the easiest way to picture it (but not truly representative). >>> That being the case, how would you describe the 5th spacial dimension. >>> That'll twist your noggin if it's not something you've thought of before :) >> One fictional contemplation of the 4th and 5th >> dimensions:https://johnesimpson.com/pdf/Ifth_of_oofth-waltertevis.pdf >> ___ > > > ___ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Question about "the screen" property of stacks...
Sorry, one more question:
I assume since 'the screen of stack' is calculated dynamically, that in
a 'on desktopChanged' handler (triggered by a monitor being removed)
that looking at 'the screen of stack' for a stack on the now-removed
monitor would give you the closest remaining monitor?
On 7/11/2019 1:08 PM, Mark Waddingham via use-livecode wrote:
On 2019-07-11 17:17, Paul Dupuis via use-livecode wrote:
The screen of stack X returns the number of the monitor (the line
number for the screenRects) that the stack/window is on.
If someone from the mothership can verify, I would be happy to open a
doc bug, update the dictionary, and generate a PR for an update to the
screen property Dictionary entry to clarify these two points.
The engine compares the content rect (not effective!) of the stack to the
working area of each screen and takes the screen with which it shares the
most area (the intersection of the stack's rect and the working area rect
of the screen is a rectangle - and its the area of that which is used).
If the stack's rect has no intersection with any screen working area then
it uses the screen which has the closest center point to the window's
center
point (by calculating the length of the line between the two points).
Ties are by display index - the primary display is always first, the rest
are in order as given by the OS to LC.
To be completely unambiguous - here is the routine the engine uses (in
the
case asked, the p_rectangle would be the rect of the stack being
interrogated):
const MCDisplay *MCUIDC::getnearestdisplay(const MCRectangle&
p_rectangle)
{
MCDisplay const *t_displays;
uint4 t_display_count;
uint4 t_home;
uint4 t_max_area, t_max_distance;
uint4 t_max_area_index, t_max_distance_index;
t_display_count = MCscreen -> getdisplays(t_displays, false);
t_max_area = 0;
t_max_distance = MAXUINT4;
t_max_distance_index = 0;
for(uint4 t_display = 0; t_display < t_display_count; ++t_display)
{
MCRectangle t_workarea;
t_workarea = t_displays[t_display] . workarea;
MCRectangle t_intersection;
uint4 t_area, t_distance;
t_intersection = MCU_intersect_rect(p_rectangle, t_workarea);
t_area = t_intersection . width * t_intersection . height;
uint4 t_dx, t_dy;
t_dx = (t_workarea . x + t_workarea . width / 2) -
(p_rectangle . x + p_rectangle . width / 2);
t_dy = (t_workarea . y + t_workarea . height / 2) -
(p_rectangle . y + p_rectangle . height / 2);
t_distance = t_dx * t_dx + t_dy * t_dy;
if (t_area > t_max_area)
{
t_max_area = t_area;
t_max_area_index = t_display;
}
if (t_distance < t_max_distance)
{
t_max_distance = t_distance;
t_max_distance_index = t_display;
}
}
if (t_max_area == 0)
t_home = t_max_distance_index;
else
t_home = t_max_area_index;
return _displays[t_home];
}
[ And yes - I just noticed that 't_max_distance' is a misnomer - it
should really be
t_min_distance! ]
Hope this helps!
Warmest Regards,
Mark.
P.S. The reason it works without a stack being open is because it is
an entirely
'logical' operation based on the rect of the stack not effective rect.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Best Practice with Player object to determine audio or video
Built-in "mediaTypes" property is pretty handy! Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.com/ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Question about "the screen" property of stacks...
Thank you Mark!
I will create an abbreviated summary for the Dictionary entry.
I can now see why the programmer will get a screen number for the stack
even if the stack is not "on" any actually monitor (use loc to screenLoc
line calculation), which is actually very helpful. Our application has a
preferences that allows the user to save their window placement between
sessions and we have to address the issue that a window may have been on
a monitor that is no longer present the next time our app starts up
We'd thought about just resetting the window to its default position,
but seeing this, it makes more sense to me to move the window to the
screen with the closest center.
On 7/11/2019 1:08 PM, Mark Waddingham via use-livecode wrote:
On 2019-07-11 17:17, Paul Dupuis via use-livecode wrote:
The screen of stack X returns the number of the monitor (the line
number for the screenRects) that the stack/window is on.
If someone from the mothership can verify, I would be happy to open a
doc bug, update the dictionary, and generate a PR for an update to the
screen property Dictionary entry to clarify these two points.
The engine compares the content rect (not effective!) of the stack to the
working area of each screen and takes the screen with which it shares the
most area (the intersection of the stack's rect and the working area rect
of the screen is a rectangle - and its the area of that which is used).
If the stack's rect has no intersection with any screen working area then
it uses the screen which has the closest center point to the window's
center
point (by calculating the length of the line between the two points).
Ties are by display index - the primary display is always first, the rest
are in order as given by the OS to LC.
To be completely unambiguous - here is the routine the engine uses (in
the
case asked, the p_rectangle would be the rect of the stack being
interrogated):
const MCDisplay *MCUIDC::getnearestdisplay(const MCRectangle&
p_rectangle)
{
MCDisplay const *t_displays;
uint4 t_display_count;
uint4 t_home;
uint4 t_max_area, t_max_distance;
uint4 t_max_area_index, t_max_distance_index;
t_display_count = MCscreen -> getdisplays(t_displays, false);
t_max_area = 0;
t_max_distance = MAXUINT4;
t_max_distance_index = 0;
for(uint4 t_display = 0; t_display < t_display_count; ++t_display)
{
MCRectangle t_workarea;
t_workarea = t_displays[t_display] . workarea;
MCRectangle t_intersection;
uint4 t_area, t_distance;
t_intersection = MCU_intersect_rect(p_rectangle, t_workarea);
t_area = t_intersection . width * t_intersection . height;
uint4 t_dx, t_dy;
t_dx = (t_workarea . x + t_workarea . width / 2) -
(p_rectangle . x + p_rectangle . width / 2);
t_dy = (t_workarea . y + t_workarea . height / 2) -
(p_rectangle . y + p_rectangle . height / 2);
t_distance = t_dx * t_dx + t_dy * t_dy;
if (t_area > t_max_area)
{
t_max_area = t_area;
t_max_area_index = t_display;
}
if (t_distance < t_max_distance)
{
t_max_distance = t_distance;
t_max_distance_index = t_display;
}
}
if (t_max_area == 0)
t_home = t_max_distance_index;
else
t_home = t_max_area_index;
return _displays[t_home];
}
[ And yes - I just noticed that 't_max_distance' is a misnomer - it
should really be
t_min_distance! ]
Hope this helps!
Warmest Regards,
Mark.
P.S. The reason it works without a stack being open is because it is
an entirely
'logical' operation based on the rect of the stack not effective rect.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Question about "the screen" property of stacks...
On 2019-07-11 17:17, Paul Dupuis via use-livecode wrote:
The screen of stack X returns the number of the monitor (the line
number for the screenRects) that the stack/window is on.
If someone from the mothership can verify, I would be happy to open a
doc bug, update the dictionary, and generate a PR for an update to the
screen property Dictionary entry to clarify these two points.
The engine compares the content rect (not effective!) of the stack to
the
working area of each screen and takes the screen with which it shares
the
most area (the intersection of the stack's rect and the working area
rect
of the screen is a rectangle - and its the area of that which is used).
If the stack's rect has no intersection with any screen working area
then
it uses the screen which has the closest center point to the window's
center
point (by calculating the length of the line between the two points).
Ties are by display index - the primary display is always first, the
rest
are in order as given by the OS to LC.
To be completely unambiguous - here is the routine the engine uses (in
the
case asked, the p_rectangle would be the rect of the stack being
interrogated):
const MCDisplay *MCUIDC::getnearestdisplay(const MCRectangle&
p_rectangle)
{
MCDisplay const *t_displays;
uint4 t_display_count;
uint4 t_home;
uint4 t_max_area, t_max_distance;
uint4 t_max_area_index, t_max_distance_index;
t_display_count = MCscreen -> getdisplays(t_displays, false);
t_max_area = 0;
t_max_distance = MAXUINT4;
t_max_distance_index = 0;
for(uint4 t_display = 0; t_display < t_display_count; ++t_display)
{
MCRectangle t_workarea;
t_workarea = t_displays[t_display] . workarea;
MCRectangle t_intersection;
uint4 t_area, t_distance;
t_intersection = MCU_intersect_rect(p_rectangle, t_workarea);
t_area = t_intersection . width * t_intersection . height;
uint4 t_dx, t_dy;
t_dx = (t_workarea . x + t_workarea . width / 2) - (p_rectangle . x +
p_rectangle . width / 2);
t_dy = (t_workarea . y + t_workarea . height / 2) - (p_rectangle . y +
p_rectangle . height / 2);
t_distance = t_dx * t_dx + t_dy * t_dy;
if (t_area > t_max_area)
{
t_max_area = t_area;
t_max_area_index = t_display;
}
if (t_distance < t_max_distance)
{
t_max_distance = t_distance;
t_max_distance_index = t_display;
}
}
if (t_max_area == 0)
t_home = t_max_distance_index;
else
t_home = t_max_area_index;
return _displays[t_home];
}
[ And yes - I just noticed that 't_max_distance' is a misnomer - it
should really be
t_min_distance! ]
Hope this helps!
Warmest Regards,
Mark.
P.S. The reason it works without a stack being open is because it is an
entirely
'logical' operation based on the rect of the stack not effective rect.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Question about "the screen" property of stacks...
It was easy enough to test. It is the loc of the stack. I would have thought the top left, but that's just me. There's good reasons for both, but I am thinking like a Mac user. The window controls for Windows are topright! Bob S > On Jul 11, 2019, at 09:27 , Paul Dupuis via use-livecode > wrote: > > But is the number accurate? > > If so, I presume it is just comparing the saved loc of the stack to the > screenRects, but what if the saved loc is not in any of the screenRects, then > what does 'the screen of stack' return? 1 by default? or something else? > > I could, of course, but a second monitor, and create a test stack to > determine all this, but some one at LiveCode should know (or be able to tell > from the code) and then, as I said, I will add it to the Dictionary entry. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Question about "the screen" property of stacks...
But is the number accurate? If so, I presume it is just comparing the saved loc of the stack to the screenRects, but what if the saved loc is not in any of the screenRects, then what does 'the screen of stack' return? 1 by default? or something else? I could, of course, but a second monitor, and create a test stack to determine all this, but some one at LiveCode should know (or be able to tell from the code) and then, as I said, I will add it to the Dictionary entry. On 7/11/2019 11:25 AM, Bob Sneidar via use-livecode wrote: Curiously, it also returns the screen number for stacks that are not open. Bob S On Jul 11, 2019, at 08:17 , Paul Dupuis via use-livecode wrote: The screen of stack X returns the number of the monitor (the line number for the screenRects) that the stack/window is on. How exactly is this determined? I presume it is based on the loc (location) property of the stack, since the window (effective rect or rect) itself can span multiple monitors, but the loc of a stack, being a point, must be one only a single monitor. However, if someone with applicable knowledge could confirm that it would be appreciated. The Dictionary does not clarify how the screen is determined. It would also help if someone could confirm that the screen value is meaningless until the stack/window is opened (much like that the effective rect is meaningless until a stack is opened)? If someone from the mothership can verify, I would be happy to open a doc bug, update the dictionary, and generate a PR for an update to the screen property Dictionary entry to clarify these two points. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Best Practice with Player object to determine audio or video
I'm looking for the best way (code), cross platform, to determine if the media a user selected for a player object is audio (only) or a video. I am surprised there is not some inherent player property to get this information. I am using an approach that looks at the formattedHeight (with audio media that should just be the height of the controller), but is there some better approach. What if, for some strange reason someone loads a 2px high video? There isn't a way to get the controler height exactly and I think it is slightly different between OSX and Windows (and I have not checked Linux or any other platform) This is our current code: getProp mediaType -- returns whether a player is showing audio, video, or none put 40 into maxControllerHeight -- magic number -- if word 1 of the name of the target is not "player" then return empty -- if the filename of the target is empty OR there is no file (the filename of the target) then return "none" -- player not loaded if the formattedHeight of the target <= maxControllerHeight then return "audio" else return "video" end mediaType However, the "40" figure bother me because it doesn't come from LiveCode itself. What if with LC10, the Mothership revised the controller and its now 41px high and the code breaks. Anyone have a better way? ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: Question about "the screen" property of stacks...
Curiously, it also returns the screen number for stacks that are not open. Bob S > On Jul 11, 2019, at 08:17 , Paul Dupuis via use-livecode > wrote: > > The screen of stack X returns the number of the monitor (the line number for > the screenRects) that the stack/window is on. > > How exactly is this determined? I presume it is based on the loc (location) > property of the stack, since the window (effective rect or rect) itself can > span multiple monitors, but the loc of a stack, being a point, must be one > only a single monitor. > > However, if someone with applicable knowledge could confirm that it would be > appreciated. The Dictionary does not clarify how the screen is determined. > > It would also help if someone could confirm that the screen value is > meaningless until the stack/window is opened (much like that the effective > rect is meaningless until a stack is opened)? > > If someone from the mothership can verify, I would be happy to open a doc > bug, update the dictionary, and generate a PR for an update to the screen > property Dictionary entry to clarify these two points. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Question about "the screen" property of stacks...
The screen of stack X returns the number of the monitor (the line number for the screenRects) that the stack/window is on. How exactly is this determined? I presume it is based on the loc (location) property of the stack, since the window (effective rect or rect) itself can span multiple monitors, but the loc of a stack, being a point, must be one only a single monitor. However, if someone with applicable knowledge could confirm that it would be appreciated. The Dictionary does not clarify how the screen is determined. It would also help if someone could confirm that the screen value is meaningless until the stack/window is opened (much like that the effective rect is meaningless until a stack is opened)? If someone from the mothership can verify, I would be happy to open a doc bug, update the dictionary, and generate a PR for an update to the screen property Dictionary entry to clarify these two points. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
Re: math on widths doesn't add up (Sean Cole (Pi))
Great story! Bob S > On Jul 10, 2019, at 13:07 , Quentin Long via use-livecode > wrote: > > sez Sean Cole (Pi):>I've just been teaching my youngest about the 4th - nth > dimensions. Time is >> not the 4th but the 1st temporal dimension. If the 3 spatial dimensions are >> Length, height and width then the 4th is depth, ie, going inwards and >> outwards as the easiest way to picture it (but not truly representative). >> That being the case, how would you describe the 5th spacial dimension. >> That'll twist your noggin if it's not something you've thought of before :) > One fictional contemplation of the 4th and 5th > dimensions:https://johnesimpson.com/pdf/Ifth_of_oofth-waltertevis.pdf > ___ ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
