Re: use-livecode Digest, Vol 237, Issue 9
What exactly is your problem with saving with Ventura? I just tried to save from 9.6.9 with the extension rev and also with .rev~. And the stack was saved successfully. Regards, Matthias > Am 13.06.2023 um 16:47 schrieb JosebaTELUR via use-livecode > : > > Hello: > > Any release date for LiveCode 10? > Hasn't it been a long time? > > I have problems saving stacks with Ventura. With the file *.rev~ > > Un saludo. > > Joseba > > ___ > 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: use-livecode Digest, Vol 237, Issue 9
Hello: Any release date for LiveCode 10? Hasn't it been a long time? I have problems saving stacks with Ventura. With the file *.rev~ Un saludo. Joseba ___ 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: Windows OS and LC969 weirdness
@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 > : > > 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@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@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 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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription
Re: Windows OS and LC969 weirdness
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@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@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 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@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 > > >
