AVFoundation crash on codesigned application

[Giovanni via use-livecode]

Hi everybody,
we are currently experiencing a problem with an LC application that is simply 
trying to catch a picture from a webcam.
The executable works properly if it’s not code signed.
After I sign the application it crashes at the very first camera access attempt 
(when the application should get the access privileges to the device).
I.E. the following causes the crash:

cameraControlCreate myCameraControlName
put cameraControlGet(myCameraControlName, "devices") into cameraDevices

The application returns me the a log after the crash (i am not able to attach 
it due to the list file size limitation).
From line 35 of the log you can see some error related to 
com.apple.avfoundation.
This is why I think it’s related to it.

Can someone provide information about this or had the same problem?
Is there a workaround or suggestion about it?

Here follows an extract of the error log:

0   libsystem_kernel.dylib  0x7fff620c71ee __open + 10
1   com.apple.CoreFoundation0x7fff36054ba3 
_CFBundleGrokFileType + 239
2   com.apple.CoreFoundation0x7fff36054a6c 
_CFBundleGrokBinaryType + 64
3   com.apple.CoreFoundation0x7fff3612ccfd 
_CFBundleLoadExecutableAndReturnError + 405
4   com.apple.CoreFoundation0x7fff3608d8a1 
CFBundleGetFunctionPointerForName + 27
5   com.apple.CoreMedia 0x7fff3713147e 
FigRegistryItemGetFactory + 68
6   com.apple.CoreMediaIO   0x7fff372698f1 
CMIOUnitCreateFromDescription + 1351
7   com.apple.CoreMediaIO   0x7fff37256aa9 
CMIOUnitNodeInfo::Open() + 59
8   com.apple.CoreMediaIO   0x7fff37245aca 
CMIOGraph::CreateNode(unsigned int, unsigned int, OpaqueCMIOUnit*, 
CMIOUnitDescription const&, void const*, int&) + 174
9   com.apple.CoreMediaIO   0x7fff372458f7 CMIOGraphCreateNode 
+ 333
10  com.apple.avfoundation  0x7fff3212a1a1 
-[AVCaptureDeviceInput 
addInputUnitsForInputPort:toGraph:ofCaptureSession:error:] + 609
11  com.apple.avfoundation  0x7fff32129df2 -[AVCaptureSession 
_buildGraphUnitsForInputPort:error:] + 727
12  com.apple.avfoundation  0x7fff320f8280 -[AVCaptureSession 
_buildAndRunGraph] + 659
13  com.apple.avfoundation  0x7fff320fcb48 -[AVCaptureSession 
_setRunning:] + 247
14  com.apple.avfoundation  0x7fff320fc9e7 -[AVCaptureSession 
startRunning] + 97

65  com.apple.AppKit0x7fff3385821a 
-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 1899
66  com.apple.AppKit0x7fff33857867 
-[NSWindow(NSEventRouting) sendEvent:] + 478
67  com.apple.AppKit0x7fff336f704f 
-[NSApplication(NSEvent) sendEvent:] + 331

74  com.apple.Foundation0x7fff383137aa 
__NSFireDelayedPerform + 411
75  com.apple.CoreFoundation0x7fff36086a60 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
76  com.apple.CoreFoundation0x7fff3608660c __CFRunLoopDoTimer + 
851
77  com.apple.CoreFoundation0x7fff36086152 __CFRunLoopDoTimers 
+ 330
78  com.apple.CoreFoundation0x7fff36067362 __CFRunLoopRun + 2130
79  com.apple.CoreFoundation0x7fff360668be CFRunLoopRunSpecific 
+ 455
80  com.apple.HIToolbox 0x7fff3535296b 
RunCurrentEventLoopInMode + 292
81  com.apple.HIToolbox 0x7fff353525ad 
ReceiveNextEventCommon + 355
82  com.apple.HIToolbox 0x7fff35352436 
_BlockUntilNextEventMatchingListInModeWithFilter + 64
83  com.apple.AppKit0x7fff336ec987 _DPSNextEvent + 965
84  com.apple.AppKit0x7fff336eb71f 
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 
+ 1361
85  com.apple.AppKit0x7fff336e583c -[NSApplication run] 
+ 699
87  libdyld.dylib   0x7fff61f913d5 start + 1

Thank you
___
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: Managing maximized windows on MacOS

[Giovanni via use-livecode]

Hi Paul,
thanks for your reply but unfortunately this workaround cannot suit the need 
for different reasons:
- the stacks that have a maxHeight lower than the height resolution of the 
screen will not be triggered by this condition;
- the condition that you suggest can be triggered manually in other conditions 
without maximizing the window (multiple screens, windows dragged over the top 
of the screen etc)

As far as I can say there is no way to detect a maximized window with the plus 
button and I think that should be tracked by LC

> Il giorno 20/nov/2019, alle ore 14:17, Paul Dupuis via use-livecode 
>  ha scritto:
> 
> On 11/20/2019 3:45 AM, Giovanni via use-livecode wrote:
>> Hi everybody,
>> as already said the main problem is that there is no way to intercept the 
>> maximization action and to understand if the window is maximized or not.
>> screenrects or windowBoundingRect are not useful in this case mainly when 
>> the maximized window has a maxWidth or maxHeight value lower than the 
>> maximum width/height of the screenrect.
>> 
>> Moreover due to the bug #21311 
>> (https://quality.livecode.com/show_bug.cgi?id=21311 
>> <https://quality.livecode.com/show_bug.cgi?id=21311>) it’s not possible to 
>> prevent the windows maximization for the resizable stacks.
>> 
>> So, any other hint about this topic?
> 
> As this is really an issue mainly on recent versions of macOS where maximize 
> goes to full screen and then really on on the primary monitor as it covers 
> things like the menu bar, I think a work-around in resizeStack is the way to 
> go. in the resizeStack handler see get the rect of the stack - this will be 
> the stacks new rect. If the top in the space normally reserved for the menu 
> bar. It doesn't have to equal the rect of the primary monitor. You just eed 
> to check the top and see if it is less than the height of the macOS menubar 
> (I think 44px?  Can't remember off the top of my head). If top is less than 
> 44px then the stack has been maximized and then you can reset the rect to the 
> effective working rect of the primary screen
> 
> so something like:
> 
> on resizeStack
>   lock screen
>   if the screen of this stack = 1 then -- this stack is on the primary monitor
>if (the effective top of this stack < (item 2 of the screenRect + 44)) 
> then -- this stack has been maximized as its top is "above" the menubar
> set the effective rect of this stack to the effective working screenRect
>end if
>   end if
>   -- do the rest of resizeStack based on the (now) revised stack rect, so 
> don't use the height or width passed as params, but get the height, width, or 
> rect after this line so you have the revised rect.
>   ...
>   unlock screen
> end resizeStack
> 
> I have not tested this - I just wrote it off the top of my head, so check to 
> see if it works.
> 
> ___
> 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: Managing maximized windows on MacOS

[Giovanni via use-livecode]

Hi everybody,
as already said the main problem is that there is no way to intercept the 
maximization action and to understand if the window is maximized or not.
screenrects or windowBoundingRect are not useful in this case mainly when the 
maximized window has a maxWidth or maxHeight value lower than the maximum 
width/height of the screenrect.

Moreover due to the bug #21311 
(https://quality.livecode.com/show_bug.cgi?id=21311 
<https://quality.livecode.com/show_bug.cgi?id=21311>) it’s not possible to 
prevent the windows maximization for the resizable stacks.

So, any other hint about this topic?


> Il giorno 12/nov/2019, alle ore 02:52, Paul McClernan via use-livecode 
>  ha scritto:
> 
> I ran into this myself recently. LiveCode sends a resizeStack message when
> you click the maximize "zoom box" button which you can intercept, but
> there's no way to verify that it was the fullscreen zoom button that
> generated the message. It would be nice if LC had the opposite of it's
> iconifyStack
> / uniconifyStack messages for maximize, maybe "fullscreenify" or something
> like that. It would also be nice if it played nice with LiveCode's
> non-native fullScreen modes, as it is now the stack automatically gets
> resized to the current screen's sized putting all the contents to the upper
> left (0,0) origin point.
> I have played around a bit with a separate LiveCode builder implementation
> macOS native fullscreen that seems to behave a bit differently, if you lock
> the resizable attributes it centers your stack on the screen without the
> resizing. It's part of this LCB library here:
> https://github.com/PaulMcClernan/LiveCode-LCB-macOSTools
> 
> On Mon, Nov 4, 2019 at 1:59 PM Giovanni via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Hi guys,
>> from MacOS Mojave and on when you maximize a window (clicking on “+”
>> button on windows main bar) the system maximize the window on the entire
>> screen hiding all the system bars and moving the window on a different
>> “virtual” space.
>> 
>> Is there a way using LC to manage this window status?
>> It’s possible to detect the window maximization (I.E. in a message) and
>> manage the actions to activate when the window goes to this status or go
>> back to the normal status?
>> 
>> Thank you in advance for your tips!
>> 
>> Regards
>> ___
>> 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

___
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

Managing maximized windows on MacOS

[Giovanni via use-livecode]

Hi guys,
from MacOS Mojave and on when you maximize a window (clicking on “+” button on 
windows main bar) the system maximize the window on the entire screen hiding 
all the system bars and moving the window on a different “virtual” space.

Is there a way using LC to manage this window status?
It’s possible to detect the window maximization (I.E. in a message) and manage 
the actions to activate when the window goes to this status or go back to the 
normal status?

Thank you in advance for your tips!

Regards
___
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: Weird behavior for modal stacks and answer dialogs

[Giovanni via use-livecode]

Hi Mark,
thank you for highlighting the 14275 report.
I can confirm the Spotify “interference” on Yosemite and Sierra. It seems to be 
ininfluent on latest version like Mojave.
I want to underline that this wrong behavior is present also in the 
executables, that is the real problem.

Is there a way to understand what’s going on with 3rd part software?


> Il giorno 09/set/2019, alle ore 17:44, Mark Waddingham via use-livecode 
>  ha scritto:
> 
> On 2019-09-09 16:16, Giovanni via use-livecode wrote:
>> Hi everybody,
>> thanks for feedback.
>> I think that the ones suggested cannot be considered as a solutions
>> nor a workarounds.
>> If I am working on an application with thousands (literally) of
>> answer/ask dialogs and modal called windows I cannot review all my
>> code to find a way to do something that the engine is called to do on
>> its own, don’t you think?
>> Anyway the “lock messages” can be used with answer/ask dialog but not
>> with modal windows that are intended to be used by the user.
>> Moreover as the modal stack behavior is correct on Windows and seems
>> to be correct on latest MacOS versions I found really strange to
>> garbage my code to workaround an issue that, in my opinion, can be
>> classified as a bug.
> 
> This sounds like <https://quality.livecode.com/show_bug.cgi?id=14275 
> <https://quality.livecode.com/show_bug.cgi?id=14275>> - the
> bug appears to be triggered when certain other apps are running but we have
> yet to be able to find out *why* these other apps have an effect on LC :(
> 
>> During my investigation I found an interesting thing: starting
>> QuickTime to produce a screencast the app starts working properly even
>> without closing/restarting it. Closing QuickTime immediately
>> reintroduce the problem. This sounds like QuickTime uses a system
>> library that LC should use but doesn’t. Can someone give an hint about
>> this?!
> 
> That is intriguing - the fact that QT makes LC's modal windows work correctly
> again is potentially quite a useful discovery. Do the machines which exhibit
> the bug have any 'always running' software (e.g. like Spotify as suggested
> in the above bug).
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com <mailto:m...@livecode.com> ~ 
> http://www.livecode.com/ <http://www.livecode.com/>
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com <mailto: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 
> <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: Weird behavior for modal stacks and answer dialogs

[Giovanni via use-livecode]

Hi everybody, 
thanks for feedback.
I think that the ones suggested cannot be considered as a solutions nor a 
workarounds.
If I am working on an application with thousands (literally) of answer/ask 
dialogs and modal called windows I cannot review all my code to find a way to 
do something that the engine is called to do on its own, don’t you think?
Anyway the “lock messages” can be used with answer/ask dialog but not with 
modal windows that are intended to be used by the user.
Moreover as the modal stack behavior is correct on Windows and seems to be 
correct on latest MacOS versions I found really strange to garbage my code to 
workaround an issue that, in my opinion, can be classified as a bug.

During my investigation I found an interesting thing: starting QuickTime to 
produce a screencast the app starts working properly even without 
closing/restarting it. Closing QuickTime immediately reintroduce the problem. 
This sounds like QuickTime uses a system library that LC should use but 
doesn’t. Can someone give an hint about this?!


> Il giorno 09/set/2019, alle ore 13:30, Paul Dupuis via use-livecode 
>  ha scritto:
> 
> On 9/9/2019 6:50 AM, Giovanni via use-livecode wrote:
>> Hi everybody,
>> I’m writing here to report a very strange behavior of modal stacks and 
>> answer dialogs on MacOS Yosemite and Sierra.
>> Basically the modal windows or dialogs, in these OSes simply does not work 
>> and this seems to happen since LC 6.7.x!
>> When you open a modal stack the expected behavior is that the script 
>> execution is interrupted and you cannot interact with the calling or other 
>> opened windows. While the first thing seems to happen, the second one 
>> doesn’t work: you can click on buttons, fields or any other control in the 
>> calling stack or any other stack opened.
>> I think that this is a very big problem mainly in porting applications from 
>> older versions of LC to the newest one and it’s quite strange that nobody 
>> else noticed this before or consider this a problem.
>> 
>> I already filed a bug report at 
>> https://quality.livecode.com/show_bug.cgi?id=22368 
>> <https://quality.livecode.com/show_bug.cgi?id=22368> in which you can also 
>> find a demo stack to easily reproduce the behavior.
>> 
>> Anyone can comment on this? Are you experiencing this as a problem? Is there 
>> a workaround or a solution for this?
>> 
>> The problem seems not to be present on Mojave but I was not able to try on 
>> other versions on MacOS and it’s not present on Windows.
>> 
>> 
> 
> This one has been around for a while, and I thought it had been previously 
> reports (but still not fixed). I seem to recall there was a lengthy 
> discussion of it on the list a long time ago.
> 
> The work-around seems to be locking things down before calling an ask or 
> answer dialog (lock messages, lock your menus and so on) so that no other 
> user actions can start any other script.
> 
> ___
> 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: 9.5 on Windows seems terribly unable to deal with fields full of text?

[Giovanni via use-livecode]

Hi Geoff,
I can confirm this and I reported this several times.
The whole IDE (the script editor mainly) is quite unusable on Windows 
workstations, no matter how many RAM or CPU is installed.
Tried all the suggestions on a lot of different Windows workstations without 
any success.
Hope that the LC developers will have the time to investigate on this issue 
that has also been reported on the QA center in different formats and confirmed 
by a lot of people.

> Il giorno 08/set/2019, alle ore 16:29, Geoff Canyon via use-livecode 
>  ha scritto:
> 
> Just running a script with large variables, no viewers open, and setting a 
> breakpoint took 20 seconds. 
> ___
> 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

Weird behavior for modal stacks and answer dialogs

[Giovanni via use-livecode]

Hi everybody,
I’m writing here to report a very strange behavior of modal stacks and answer 
dialogs on MacOS Yosemite and Sierra.
Basically the modal windows or dialogs, in these OSes simply does not work and 
this seems to happen since LC 6.7.x!
When you open a modal stack the expected behavior is that the script execution 
is interrupted and you cannot interact with the calling or other opened 
windows. While the first thing seems to happen, the second one doesn’t work: 
you can click on buttons, fields or any other control in the calling stack or 
any other stack opened.
I think that this is a very big problem mainly in porting applications from 
older versions of LC to the newest one and it’s quite strange that nobody else 
noticed this before or consider this a problem.

I already filed a bug report at 
https://quality.livecode.com/show_bug.cgi?id=22368 
 in which you can also find 
a demo stack to easily reproduce the behavior.

Anyone can comment on this? Are you experiencing this as a problem? Is there a 
workaround or a solution for this?

The problem seems not to be present on Mojave but I was not able to try on 
other versions on MacOS and it’s not present on Windows.

Regards!

--
Giovanni
___
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