Windows OS and LC969 weirdness

matthias_livecode_150811 at m-r-d.de matthias_livecode_150811 at m-r-d.de
Tue Jun 13 04:55:36 EDT 2023


@Panos,

so maybe then this bug (import/export snapshot on a system with 2 displays only works under special conditions) will also be fixed?   ;)
https://quality.livecode.com/show_bug.cgi?id=22852

> Am 13.06.2023 um 09:09 schrieb panagiotis m via use-livecode <use-livecode at lists.runrev.com>:
> 
> Hello all,
> 
> @Matthias
> Not sure, it might be the case that someone had investigated this in the
> past, but did not get far enough to push a fix. Or it might be the case we
> never got the time to look at it properly, since more important updates had
> to be addressed first (for example any issues that might break submission
> to the app stores, such as new requirements from Apple, Google etc, or
> support for new OS versions that are released), so this bug did not
> actually make it to the top of our backlog.
> I agree this is something we have to fix though, sooner or later.
> 
> @Paul
> You're welcome
> 
> Kind regards,
> Panos
> 
> On Mon, 12 Jun 2023 at 23:11, Paul Dupuis via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> 
>> Panos,
>> 
>> Thank you again for saving me a big chunk of time!
>> 
>> Yes, this sounds exactly like that bug. The same code works repeatedly
>> on a single monitor. Put the window with a player on the secondary
>> monitor and try and close it and ... freeze. I have no code doing
>> anything related to the 'screen' property of a window or treating the
>> window differently if the user moved it to a secondary monitor.
>> 
>> I could really use a fix for this one in LC 9.6.10! Primarily because it
>> does result in a engine Freeze and requires the user to force quit and
>> we have no way to ensuring a user doesn't have multiple monitor and will
>> move the media window to another monitor. And even if we did restrict
>> the window to 'screen' 1, that would just be a weird app behavior to
>> allow other windows to be moved across monitors, but not the media window.
>> 
>> Thanks again for pointing me in the right direction!
>> 
>> 
>> On 6/12/2023 2:19 PM, panagiotis m via use-livecode wrote:
>>> Hello Paul,
>>> 
>>> It sounds like this bug:
>>> 
>>> https://quality.livecode.com/show_bug.cgi?id=20707
>>> 
>>> Kind regards,
>>> Panos
>>> 
>>> On Mon, 12 Jun 2023, 21:10 Paul Dupuis via use-livecode, <
>>> use-livecode at lists.runrev.com> wrote:
>>> 
>>>> I have a weird problem and I am wondering if anyone has seen anything
>>>> like it.
>>>> 
>>>> I have an desktop app, built in Livecode 9.6.9 and running under Windows
>>>> 10 and 11. The app has stacks/windows to display different types of
>>>> content docText for text, docPDF for PDFs, docImage for images, docMedia
>>>> for player based audio or video. Only 1 of these windows can be open at
>>>> a time. If you try to call up information of another type, it closes the
>>>> current content window and opens the appropriate stack to display the
>>>> new type of information.
>>>> 
>>>> Here is the weirdness. On a single monitor system, I can switch between
>>>> these content windows endlessly
>>>> On a 2 monitor system, if all the windows are on the primary monitor, I
>>>> can switch between them endlessly
>>>> On a 2 monitor system, I can place any of the content windows EXCEPT the
>>>> media player (docMedia) on either monitor and swithc between them
>> endlessly
>>>> On a 2 monitor system, if I put the media player window on the secondary
>>>> monitor and try to switch bring up another content windows (docText,
>>>> docPDF, docImage) - whether on the primary or secondary monitor, I get
>>>> frozen app and Windows spinning blue cursor (the app is non-responsive,
>>>> like in an endless loop)
>>>> 
>>>> Now, the above is with a built standalone. If I run the app in the LC969
>>>> IDE, I get the same behavior above if I just let things run.
>>>> 
>>>> If I enter the debugger, the code sequence is roughly:
>>>> 
>>>> a) if the new info to display is of a different type that the current;y
>>>> displayed info, then
>>>>      test in a loop through the app's open windows to see if one of
>>>> these content windows is open and then close stack <name> to close it
>>>> b) open the applicable window for the new information and display it
>>>> 
>>>> If I walk through, in the IDE debugger, every line single line by single
>>>> line, it all works, including stepping through the stack 'closeStack'
>>>> handler
>>>> If I tell the debugger to run through the code above, rather than step
>>>> line by line, the freeze happens
>>>> 
>>>> But again, ONLY when the docMedia window (with a player object and a few
>>>> fields and buttons) is on a secondary monitor.
>>>> 
>>>> Has anybody seen any weirdness like this? The fact I can debug through
>>>> it line by line and it does not freeze means finding what may be
>>>> triggering it seem very hard (to me at least).
>>>> 
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> use-livecode at 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 at 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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



More information about the use-livecode mailing list