LiveCode Forums.

Since few days, I experiment this strange behavior:

Context: Mac - Yosemite - LC 6.7.5 Commercial or LC 6.7.6 Community Edition.

1) Open the Activity monitor

2) open LC from the Dock.

3) Select Menu File->Open stack

4) Go for a coffee... for almost 30 seconds!
During this time, can't interact with anything else.
Even the activity monitor is fully blocked

5) Have back the control, the activity monitor screen is updated,
and here a screenshot of the past OS activity (blue) 6) Re-selecting File->Open stack a second time, it works fine.

7) Closing LC and repeating this process, it stucks again.

Any other apps on this Mac are behaving correctly.


Any clue or already known bug about this?

Thanks

Thierry

A bit more information of this annoying behavior

1) Open Livecode ( same versions and context as the 1st post)

2) Open a recent stack; works as expected.

3) Menu: File->Save as...
It also blocks everything for 20 seconds at least

4) second try is fine.

5) If after opening a stack (with the blocking behavior),
the "Save as..' sub-menu works fine too.


and the joker:
with the sub-menu "Save as..."
I can open as many dialog box as I want at the same time.
never saw that before????

Regards,

Thierry

Bonjour Thierry,

I also see this on my Mac, but this is not a LC issue, this also happens in ANY other programm!

I think this has to do with a "spinned down" TimeMachine harddisk, which need to "spin up" (?) again
and check before writing to disk. This IS in fact very annoying!


Best

Klaus

Klaus wrote: I also see this on my Mac,
but this is not a LC issue, this also happens in ANY other programm!

I think this has to do with a "spinned down" TimeMachine harddisk,

Vielen Dank, Klaus.

Not true here, TimeMachine is inactive on my Mac!

This is something else and definitively a LC bad behavior
as long as someone else prooves me the opposite!

Bon week-end,

Thierry

PS: Out of curiosity, do you have an old Mac or old OS?

Bonjour Thierry,

ah, OK, just a thought.
But that is obviously the case here, MacMini i7 with OS X 10.10.4


Best

Klaus

Klaus wrote: ah, OK, just a thought.

No problem.
Sometimes, others thought give us an insight if not the solution.
So thanks again for your post.

But that is obviously the case here, MacMini i7 with OS X 10.10.4

Mmm, no comments.

mit freundlichen grüßen

Thierry

I see the same behavior that Thierry sees, the first time the Mac file system is accessed it takes a long time for Livecode to respond.
Further accesses to the file system are snappy. (save a stack, save as etc.)

No timeMachine currently attached.

I thought I was the only one experiencing this because of a slow disk, but other applications are faster.

Does anyone have a clue as to what is happening? Or is it just isolated cases?
MacBook Pro 2010, processor i5 at 2.5.3 MHz, MacOSX 10.9.5, Livecode any version of the 6 and 7 series.

Kind regards

Bernd

Hi all,

presumably it is not caused by LC but you have corrupt Finder preferences
[possible test: "set systemfileselector to false" works much faster]

This helped me recently for ALL applications, not only LC (use terminal):
This clearly removes finder preferences
(default new window, tab prefs, desktop, sidebar, view and search prefs etc.), but you have a copy ...

If problems are still there you could have a look here:
osxdaily.com/2013/11/24/slow-open-save-dialog-problem-mac-os-x/

Have a nice and fast sunday!

Hi Hermann,

good to see you again. I will try your suggestion. If you don't hear from me I probably blew up my computer via terminal.

Kind regards

Bernd

Hi Bernd,

don't blame me or terminal if you try to open a folder with thousands of objects (Pictures, LC stacks, Applications) while Finder is allowed to show previes in column view.

Also, when saving a newly created stack, the defaultfolder(!) is the one where LC is in, with a lot of bundles that are 'inspected' for the default system dialog. This needs still a few seconds here (Mac mini or MBP).

Hermann

Hi Hermann,

I tried the terminal trick and it did delete the finder preferences. But the rest is unchanged.

No idea what is going on.

It is not a couple of seconds but more like 20.

But it did speed up Mail start up time, which is a good think.

Anyway thanks

Kind regards
Bernd

Hi,

Spent half a day yesterday on this topic

I did follow the IDE script to quickly jump to the "answer files".

Then, I tried with a stack and a button:
Same behavior!

I've cleaned everything possible on my Mac ( Onyx, disk utility,..).
This behavior is *only* with LC ( different versions); all my other apps are behaving correctly.

@[hh]: I thought 'answer file' was using the default folder but it's not true.
It uses the folder used by the latest answer file call (it's even in the dictionary)
and for the record, it's saved in ~/Preferences/com.runrev.livecode.plist

I've deleted this file and also the Preferences stack ( livecode.rev or livecode7.rev)


Other thoughts?

Is it fine to change the title of this thread, as this one is not accurate anymore?

Regards,

Thierry

Hi all,

my Mac here approaches again the behaviour you describe extremely with LC, but slightly also with all apps (OS 10.10.5). Meanwhile, after starting an open/save dialog in LC@Mac, I switch the screen to a RaspberryPi and look what it has done (math jobs).

But there are good news for Mac OS 10.11.:
The latest beta version 8 has the old fast behaviour for open/save dialogs, even for a folder of 2500 images, also with LC 6/7/8 and its answer/ask dialogs.

Let us hope, that this is stable and Safari 9 (showing rotating wheels after rotating wheels after rotating wheels) will be improved.

Hermann

Hi,

@ [-hh] : glad you find that in paradise, LC will work...

Unfortunately, my current customer will not appreciate this story at all.

and the delay I and few others are experimenting is around 20 seconds !

Kind regards,

Thierry

Hi Thierry,

just looking for a way out of this, I see your nasty problem:

If I need frequently answer file/ask file/save/open then I use
"set systemfileselector to false"
This works very fast for me.

It's not a beauty, the dialog stack (from resources), but perhaps your customer prefers "speed" to "design"?
And you can even edit these dialog stacks and beautify or enhance it if needed.

Kind regards.
Hermann