System:
Win10
Regina REXX 3.8 (yes, I know I should update).

Situation:
In one command window, I issue w32clipopen and wait for a keystroke.
While that's waiting, I issue w32clipopen in a different command
window, and it gets return code 1 (i.e. successful).

Am I doing something wrong? Is this working as designed?

If the answers are "no" and "yes", I don't understand the usefulness
of w32clipopen and would appreciate an explanation.

--
Arthur T. - ar23hur "at" pobox "dot" com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 05 Mar 2022 15:49:38 -0500, Arthur T. <arthur@munged.invalid>
declaimed the following:

Situation:
In one command window, I issue w32clipopen and wait for a keystroke.
While that's waiting, I issue w32clipopen in a different command
window, and it gets return code 1 (i.e. successful).

Am I doing something wrong? Is this working as designed?

Hopefully someone with exposure will step in...

I'm curious as to where this w32clipopen is coming from -- Google has NO HITS on that term, and I find nothing with that name in either ooREXX
5.x, nor Regina 3.9.4 (ooREXX does have a clipboard class documented in its win32 extensions package).


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Message-ID:<uhk72htcg4rbt1b4q84vdh3cuuhf6c86vr@4ax.com>,
Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

I'm curious as to where this w32clipopen is coming from -- Google has
NO HITS on that term, and I find nothing with that name in either ooREXX
5.x, nor Regina 3.9.4 (ooREXX does have a clipboard class documented in its >win32 extensions package).

Sorry. Regina REXX also has a w32funcs extension and that's where it
comes from. The first few lines of my test program are:

call rxfuncadd 'w32loadfuncs', 'w32util', 'w32loadfuncs'
call w32loadfuncs

y = w32clipopen()

--
Arthur T. - ar23hur "at" pobox "dot" com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 05 Mar 2022 17:18:14 -0500, Arthur T. <arthur@munged.invalid>
declaimed the following:

Sorry. Regina REXX also has a w32funcs extension and that's where it
comes from. The first few lines of my test program are:

Which also had no direct hits in Google -- just some very old entries on sites like StackOverflow... I finally found a link (on a page asking how
to manipulate Word documents from REXX!).

Suspect it won't do anything for me -- given the age of the download, it is likely a 32-bit DLL and I have 64-bit Regina installed (and even that
is problematic; entering "regina some.rexx" on a command line results in
zero output, just a return to command prompt. "rexx some.rexx" works, but
is the version with no dynamic library loading. "some.rexx" alone seems to start regina, but for use in a command line I had to change the association
to remove the -p [pause at end] option). I'm pretty certain mixed length libraries are not supported by Windows.

call rxfuncadd 'w32loadfuncs', 'w32util', 'w32loadfuncs'
call w32loadfuncs

y = w32clipopen()

From the documentation (for the close operation)

"""
One should close the clipboard as soon as possible after opening it, since other applications are not able to use the clipboard while it is open.
"""

It also indicates that explicit open/close is only needed if one is going to be doing a set of close spaced operations (putting data into the clipboard using multiple formats, for example). Otherwise, an implicit open/operation/close is done.



I would suspect your second attempt to open the clipboard is returning with a fail status, as the first task has it locked. Your sample code above
is never testing return codes from the calls, or from the functions
themselves.



--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Message-ID:<q7v72h9n9ir9ik8sijsuhro4qen1rr92e4@4ax.com>,
Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

I would suspect your second attempt to open the clipboard is returning
with a fail status, as the first task has it locked. Your sample code above >is never testing return codes from the calls, or from the functions >themselves.

That's what I expected. I've now made as simple a program as I could
to test it. The invocation of w32clipopen is copy-and-pasted directly
from the manual (except I'm using actual single quotes):

<code>
call rxfuncadd 'w32loadfuncs', 'w32util', 'w32loadfuncs'
call w32loadfuncs

if \w32ClipOpen() then do
say 'Failed to open the clipboard'
exit 1
end

say "Hit <Enter> to end."
pull ans

x = w32clipClose()
</code>

I run it in one command prompt window. While it's waiting for me to
hit Enter, I run it on another command prompt window. I then have
both windows waiting for me to hit Enter, which means that neither
failed to open the clipboard. Hence my wondering if I'm doing
something wrong, if my reasoning is wrong, or if there's either a bug
or documentation problem.

--
Arthur T. - ar23hur "at" pobox "dot" com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 05 Mar 2022 21:45:41 -0500, Arthur T. <arthur@munged.invalid>
declaimed the following:

I run it in one command prompt window. While it's waiting for me to
hit Enter, I run it on another command prompt window. I then have
both windows waiting for me to hit Enter, which means that neither
failed to open the clipboard. Hence my wondering if I'm doing
something wrong, if my reasoning is wrong, or if there's either a bug
or documentation problem.

At this point, I couldn't say... However, https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-operations#clipboard-ownership
has an interesting (and confusing) comment:
"""
A window becomes the clipboard owner when it places data on the clipboard, specifically, when it calls the EmptyClipboard function.
"""
(apparently one has to empty anything some other application put into it to take ownership). Perhaps open alone is sort of a do-nothing? (though that
would be counter to:
"""
To place data on or retrieve data from the clipboard, a window must first
open the clipboard by using the OpenClipboard function. Only one window can have the clipboard open at a time.
"""
... perhaps open just sets a shared /read/ status, with locking taking
place only when a task invokes empty. After all, one can paste clipboard contents into multiple windows without taking ownership -- it is the
cut/copy that has to own the clipboard)

Might I suggest attempting to put the library equivalent of the empty call between the open and your console read statement?


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Message-ID:<juo92hdc64o75mkltluaoeng4g9g7h1197@4ax.com>,
Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

At this point, I couldn't say... However,
https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard-operations#clipboard-ownership
has an interesting (and confusing) comment:
"""
A window becomes the clipboard owner when it places data on the clipboard, >specifically, when it calls the EmptyClipboard function.
"""
(apparently one has to empty anything some other application put into it to >take ownership). Perhaps open alone is sort of a do-nothing?
"""

<snip>

Might I suggest attempting to put the library equivalent of the empty
call between the open and your console read statement?

Thanks for finding that link, but it doesn't seem to be my problem.

I called the empty function between the open and the console read. No difference. I then actually updated the clipboard after the empty,
and again no difference (but the clipboard was actually updated).

So, I'm leaning towards "bug". Before I report it, I'll have to get
the newest Regina and (if there's a newer one) newest W32Funcs and
try again.

It's going to be quite a while before I can justify the amount of
time needed to properly document a bug report, so that's not going to
happen soon. I take reporting bugs seriously, and try to make my
report terse, yet complete and correct.

But, again, thanks for your help.

--
Arthur T. - ar23hur "at" pobox "dot" com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 06 Mar 2022 16:22:26 -0500, Arthur T. <arthur@munged.invalid>
declaimed the following:

I called the empty function between the open and the console read. No >difference. I then actually updated the clipboard after the empty,
and again no difference (but the clipboard was actually updated).

So, I'm leaning towards "bug". Before I report it, I'll have to get
the newest Regina and (if there's a newer one) newest W32Funcs and
try again.

http://home.interlog.com/~ptjm/software.html
W32 Funcs 1.5.1 19 December 2003

is the only reference I've found for it.

Includes source files so...

I'm now pondering (I've never studied exactly how DLLs operate on Windows)...

-=-=-
static int ocb(int open)
{
static int opencount;
int rc = TRUE;

if (open && !opencount++) {
rc = OpenClipboard(NULL);
}
else if (!--opencount) {
rc = CloseClipboard();
}

/* try to avoid issues with excess calls to w32clipclose */
if (opencount < 0)
opencount = 0;

return rc;
}
-=-=-

"opencount" is declared static within that function. As I recall my C, that means it retains its value between invocations of the function (ie; is neither stack nor heap allocated).

BUT for a shared library/DLL -- does static mean all users of the DLL see the same opencount, or is "static" memory allocated per connecting
process. Microsoft documentation suggests the latter -- otherwise I could
see the open returning success.

-=-=-
rxfunc(w32clipopen)
{
result->strlength = sprintf(result->strptr, "%d", ocb(1));
return 0;
}

rxfunc(w32clipclose)
{
result->strlength = sprintf(result->strptr, "%d", ocb(0));
return 0;
}
-=-=-

It's going to be quite a while before I can justify the amount of
time needed to properly document a bug report, so that's not going to
happen soon. I take reporting bugs seriously, and try to make my
report terse, yet complete and correct.

But is anyone working on those libraries <G> There doesn't seem to have been any work since 2004. The last activity by the author, in this
newsgroup, was March 11 2008. (Now to work on killing the downloading of
14K messages!)



--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In Message-ID:<0paa2hpicgannfbj55ufeaoh8vgrd0sahe@4ax.com>,
Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

It's going to be quite a while before I can justify the amount of
time needed to properly document a bug report, so that's not going to >>happen soon. I take reporting bugs seriously, and try to make my
report terse, yet complete and correct.

But is anyone working on those libraries <G> There doesn't seem to have
been any work since 2004. The last activity by the author, in this
newsgroup, was March 11 2008. (Now to work on killing the downloading of
14K messages!)

There appears to be exactly one person (Mark Hessling) working on
Regina. I haven't seen any activity from Mr. McPhee for quite a
while, but that doesn't mean I'll give up hope.

But it does mean I'm not going to depend on clipboard locking any
time in the near future. (I'm also not going to try modifying the
source code, myself. I'm more likely to cause errors than fix them.)

--
Arthur T. - ar23hur "at" pobox "dot" com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)