"Use" locks shared objects by locker ID.
if you write
Storage.prop:=New shared object
trace it, and enabled "display type" in the debugger pane,
you would see that the locker id of Storage is -7 (don't ask me why).
Storage.prop would be -15 (ditto)
Keith, that doesn't seem to work on Windows unfortunately.
Miyako, Thanks for the link to your 2 plugins. I should have known to
check your GitHub account. ;-)
I tried both of your plugins. Set Window Title for the MDI window works
perfectly, but I couldn't get the icon to be set correctly.
No locking occurs with "Use (Storage)” by itself.
But locking does occur for **first level** attributes of Storage.
So “Use (Storage.pref)” performs locking in other processes.
To prevent “Storage.pref” from being updated in a separate process, call:
When using „use“, all operations are atomic.
[heubach-media] | Christian Sakowski
Tel: +49/(0)40/52 10 59-23
> Am 01.02.2019 um 22:45 schrieb David Ringsmuth via 4D_Tech
> My test show that
My test show that
Does not lock Storage.pref, and does not prevent Storage.pref from being
updated in a separate process.
By lock, I mean that during use(Storage) in process A, use(Storage.pref) in
process B will execute without waiting.
By update I mean that
When using the close box of the Application window in 32-bit the form method of
the frontmost window is triggered.
However, when using the close box of the MDI Application window in 64-bit
Does anybody know why this is?
Mail list logo