f



Accessing clipboard from REXX DLL

I'm trying to write a function in a REXX libary that needs to
access the clipboard.

The problem is, WinSetClipbrdData() is failing with error code
1009, which seems to be PMERR_CALL_FROM_WRONG_THREAD.  I notice
that PMREF says the following:

  The operating system does not generally use the information 
  supplied by the hab parameter to its calls; instead, it 
  deduces it from the identity of the thread that is making the call. 

I guess this means it's unable to "deduce" the anchor block
handle from the identity of the thread in this case.  (I currently
have a call to WinInitialize() directly before the WinSetClipbrdData()
function.  I also tried removing it and just using 1 for the
hab parameter.)

I was kind of expecting this function to fail when called from
a standard (i.e. non-PM) REXX program.  However, the same error
occurs when I run the script under PMREXX.

I know there are REXX DLLs which do this.  So how can I write
to (and read from) the clipboard in a REXX library function?

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/12/2007 3:12:02 PM
comp.os.os2.programmer.misc 1326 articles. 0 followers. Post Follow

93 Replies
527 Views

Similar Articles

[PageSpeed] 51

Alex Taylor wrote:
> I'm trying to write a function in a REXX libary that needs to
> access the clipboard.
> 
> The problem is, WinSetClipbrdData() is failing with error code
> 1009, which seems to be PMERR_CALL_FROM_WRONG_THREAD.  I notice
> that PMREF says the following:
> 
>   The operating system does not generally use the information 
>   supplied by the hab parameter to its calls; instead, it 
>   deduces it from the identity of the thread that is making the call. 
> 
> I guess this means it's unable to "deduce" the anchor block
> handle from the identity of the thread in this case.  (I currently
> have a call to WinInitialize() directly before the WinSetClipbrdData()
> function.  I also tried removing it and just using 1 for the
> hab parameter.)
> 
> I was kind of expecting this function to fail when called from
> a standard (i.e. non-PM) REXX program.  However, the same error
> occurs when I run the script under PMREXX.
> 
> I know there are REXX DLLs which do this.  So how can I write
> to (and read from) the clipboard in a REXX library function?
> 

As a wild guess, and just looking at the clipboard api's,
have you tried doing a WinOpenClipbrd first?

Bob Plyler
0
Bob
12/12/2007 3:31:09 PM
In article <mdq090pMZSKk-pn2-KNB8VMzW7MKu@localhost>,
"Alex Taylor" <mail.me@reply.to.address> wrote:
>I'm trying to write a function in a REXX libary that needs to
>access the clipboard.
>
>The problem is, WinSetClipbrdData() is failing with error code
>1009, which seems to be PMERR_CALL_FROM_WRONG_THREAD.  I notice
>that PMREF says the following:
>
>  The operating system does not generally use the information 
>  supplied by the hab parameter to its calls; instead, it 
>  deduces it from the identity of the thread that is making the call. 
>
>I guess this means it's unable to "deduce" the anchor block
>handle from the identity of the thread in this case.  (I currently
>have a call to WinInitialize() directly before the WinSetClipbrdData()
>function.  I also tried removing it and just using 1 for the
>hab parameter.)
>
>I was kind of expecting this function to fail when called from
>a standard (i.e. non-PM) REXX program.  However, the same error
>occurs when I run the script under PMREXX.
>
>I know there are REXX DLLs which do this.  So how can I write
>to (and read from) the clipboard in a REXX library function?
>
>-- 
>Alex Taylor
>http://www.cs-club.org/~alex
>
>Please take off hat when replying.

0
spamgate
12/12/2007 8:00:55 PM
 >> I'm trying to write a function in a REXX libary that needs to
 >> access the clipboard.

groups.google.com & "clipboard utility group:comp.os.os2.programmer.misc"
should provide some applyable inspiration.



---
0
spamgate
12/12/2007 8:12:06 PM
In <mdq090pMZSKk-pn2-KNB8VMzW7MKu@localhost>, on 12/12/2007
   at 09:12 AM, "Alex Taylor" <mail.me@reply.to.address> said:

Hi,

>The problem is, WinSetClipbrdData() is failing with error code 1009,
>which seems to be PMERR_CALL_FROM_WRONG_THREAD.  I notice that PMREF says
>the following:

I recommend you post something specific here so we can see exactly what
parameters you are using.

I suspect you are trying to use a handle as one of the parameters.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
12/12/2007 9:00:38 PM
On Wed, 12 Dec 2007 15:31:09 UTC, Bob Plyler <rplyler@no.spam.us.ibm.com> 
wrote:

> > The problem is, WinSetClipbrdData() is failing with error code
> > 1009, which seems to be PMERR_CALL_FROM_WRONG_THREAD.  
> 
> As a wild guess, and just looking at the clipboard api's,
> have you tried doing a WinOpenClipbrd first?

Um... doh!

<sigh> Thanks.  To be fair, that wasn't the ONLY problem with
my code, but fixing it allowed me to track the other one down.

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/13/2007 4:39:01 AM
On Wed, 12 Dec 2007 21:00:38 UTC, Steven Levine <steve53@earthlink.bogus.net> 
wrote:

> >The problem is, WinSetClipbrdData() is failing with error code 1009,
> >which seems to be PMERR_CALL_FROM_WRONG_THREAD.  I notice that PMREF says
> >the following:
> 
> I recommend you post something specific here so we can see exactly what
> parameters you are using.
> 
> I suspect you are trying to use a handle as one of the parameters.

Simpler answer, found thanks to Bob.  First of all, I forgot to
call WinOpenClipbrd() (that's what I get for reusing code without
being more careful).  The copy of the desired text into the shared 
memory buffer was also failing, because an earlier function call 
had reset the variable I was using to hold the string length to 0.

It works now.  Interestingly, it works even when the REXX is not
running as a PM process (although I'm sure it would fail if PM
were not running at all).

Thanks!
-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/13/2007 4:44:01 AM
In <mdq090pMZSKk-pn2-EomMxd8dBc2M@13.1.168.192.in-addr.arpa>, on
12/12/2007
   at 10:44 PM, "Alex Taylor" <mail.me@reply.to.address> said:

>Simpler answer, found thanks to Bob.  First of all, I forgot to call
>WinOpenClipbrd() (that's what I get for reusing code without being more
>careful).

This is one of the cases where the pmref examples are actually correct.
:-)

>It works now.  Interestingly, it works even when the REXX is not running
>as a PM process (although I'm sure it would fail if PM were not running
>at all).

Yes, I noticed this in the 4OS2 which supports the CLIP: pseudo-device.

It makes sense because while PM manages the clipboard, the content is not
necessarily associated with a window.  The association is only required
when the application placing the data in the clipboard is going to render
it.  As least, that's my understanding of how it works.

I can't say that I care much for the error message which is somewhat
misleading.  If the message contained the word open, it would have been
pretty obvious what was wrong.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
12/13/2007 6:07:18 AM
OK, now I have another problem.  

Before, I was writing to the clipboard.  Problem solved, it now
works.

Now I'm writing a function that reads from the clipboard, and it
just isn't working.  Specifically, WinQueryClipbrdData() is
returning a non-null value (allegedly a pointer) as it's supposed 
to... but any attempt I make to use that data results in a SYS3175.

Here's the code that writes to the clipboard (some error checking
deleted for clarity).  This works as it should.

    if ( ulRC == ULS_SUCCESS ) {
        hSATbl = WinQuerySystemAtomTable();
        cf_TextUnicode = WinAddAtom( hSATbl, "text/unicode");

        hab = WinInitialize( 0 );
        if ( hab ) {
            if ( WinOpenClipbrd( hab )) {
                stOutLength = argv[0].strlength;
                ulRC = DosAllocSharedMem( (PVOID) &psuShareMem, NULL, 
                                           stOutLength + 1,
                                           PAG_WRITE | PAG_COMMIT | 
                                           OBJ_GIVEABLE );
                if ( ulRC == 0 ) {
                    UniStrncpy( psuShareMem, psuConverted, stOutLength );
                    WinSetClipbrdData( hab, (ULONG) psuShareMem, 
                                       cf_TextUnicode, CFI_POINTER );
                } 
                WinCloseClipbrd( hab );
            } 
            WinTerminate( hab );
        } 
        WinDeleteAtom( hSATbl, cf_TextUnicode );
        free( psuConverted );
    } 


However, the following, which was lifted directly from another
program that does work (albeit an executable, not a DLL like this),
fails.  

    // Make sure the Unicode clipboard format is registered
    hSATbl = WinQuerySystemAtomTable();
    cf_TextUnicode = WinAddAtom( hSATbl, "text/unicode");

    // Initialize the PM API and open the clipboard
    hab = WinInitialize( 0 );
    if ( hab ) {
        ulRC = WinOpenClipbrd( hab );
        if ( ulRC ) {
            if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab, 
                                            cf_TextUnicode )) != NULL ) {
                // ...

Any attempt to do anything with psuClipText after this point 
generates a trap (although the value is indeed non-NULL).


Any suggestions?  I'm out of ideas.
-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/14/2007 2:27:02 PM
In <mdq090pMZSKk-pn2-Vu0XrJgdxTkO@localhost>, on 12/14/2007
   at 08:27 AM, "Alex Taylor" <mail.me@reply.to.address> said:

Hi,

>Now I'm writing a function that reads from the clipboard, and it just
>isn't working.  Specifically, WinQueryClipbrdData() is returning a
>non-null value (allegedly a pointer) as it's supposed  to... but any
>attempt I make to use that data results in a SYS3175.

This is a VIO app, isn't it?  Well, I dimly recalled something in the 4OS2
sources.  It says

// kludge for OS/2 bug - it doesn't make
//  clipboard memory readable for VIO apps!
if ( DosGetSharedMem( lpClipMemory, PAG_READ ) != 0 )
        lpClipMemory = NULLSTR;

I assume you have printed out the pointer value and it appears to point to
otherwise valid shared memory.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
12/14/2007 4:44:07 PM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Steven Levine 
<steve53@earthlink.bogus.net>], who wrote in article <4762b375$1$fgrir53$mr2ice@news.west.earthlink.net>:
> This is a VIO app, isn't it?  Well, I dimly recalled something in the 4OS2
> sources.  It says
> 
> // kludge for OS/2 bug - it doesn't make
> //  clipboard memory readable for VIO apps!
> if ( DosGetSharedMem( lpClipMemory, PAG_READ ) != 0 )
>         lpClipMemory = NULLSTR;
> 
> I assume you have printed out the pointer value and it appears to point to
> otherwise valid shared memory.

Aha, this is why in my clipboard functions (readline/Perl/Lynx), I
needed to morph to PM first...

Thanks,
Ilya
0
Ilya
12/14/2007 10:16:35 PM
On Fri, 14 Dec 2007 16:44:07 UTC, Steven Levine <steve53@earthlink.bogus.net> 
wrote:

> >Now I'm writing a function that reads from the clipboard, and it just
> >isn't working.  Specifically, WinQueryClipbrdData() is returning a
> >non-null value (allegedly a pointer) as it's supposed  to... but any
> >attempt I make to use that data results in a SYS3175.
> 
> This is a VIO app, isn't it?  

Well, a REXX library, so I assume it depends on how the REXX
process is started.  

> Well, I dimly recalled something in the 4OS2
> sources.  It says
> 
> // kludge for OS/2 bug - it doesn't make
> //  clipboard memory readable for VIO apps!
> if ( DosGetSharedMem( lpClipMemory, PAG_READ ) != 0 )
>         lpClipMemory = NULLSTR;

Oh, interesting!  But the same error occurs when I run the
REXX script under PMREXX, shouldn't that turn it into a PM
process?

 
> I assume you have printed out the pointer value and it appears to point to
> otherwise valid shared memory.

Well, it's a normal-looking 32-bit integer value.  I have no 
idea how to tell if it's "valid shared memory" or not, though.


(Incidentally, is there any way to run a REXX library function
through icsdebug or something equivalent?)
-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/15/2007 12:00:03 AM
On 14 Dec 2007 18:00:03 -0600, Alex Taylor <mail.me@reply.to.address> wrote:

> (Incidentally, is there any way to run a REXX library function
> through icsdebug or something equivalent?)

Yeah, just debug CMD.EXE and set a DLL load breakpoint. Then you can set
other breakpoints in your DLL.
0
Paul
12/15/2007 1:57:57 AM
In <mdq090pMZSKk-pn2-6NDln9Xrcgno@localhost>, on 12/14/2007
   at 06:00 PM, "Alex Taylor" <mail.me@reply.to.address> said:

Hi,

>Oh, interesting!  But the same error occurs when I run the
>REXX script under PMREXX, shouldn't that turn it into a PM
>process?

One would think so, but who knows.  We will know soon enough when you try
with DosGetShared memory.

>Well, it's a normal-looking 32-bit integer value.  I have no  idea how to
>tell if it's "valid shared memory" or not, though.

The easy way is to display the value in hex and then ask Theseus to tell
you what it knows about the address.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
12/15/2007 5:18:48 AM
On Sat, 15 Dec 2007 05:18:48 UTC, Steven Levine <steve53@earthlink.bogus.net> 
wrote:

> >Oh, interesting!  But the same error occurs when I run the
> >REXX script under PMREXX, shouldn't that turn it into a PM
> >process?
> 
> One would think so, but who knows.  We will know soon enough when you try
> with DosGetShared memory.

If you mean the 4OS2 workaround you posted, I added it and it
removes the crash.  However, it ALWAYS returns non-zero... even
when run under PMREXX or from a VX-REXX program.  So my function
still doesn't work, even if it no longer crashes.

 
> >Well, it's a normal-looking 32-bit integer value.  I have no  idea how to
> >tell if it's "valid shared memory" or not, though.
> 
> The easy way is to display the value in hex and then ask Theseus to tell
> you what it knows about the address.

Ah.  Not sure if I have Theseus on my laptop... if I'm confined
to using it full-time for much longer I should probably think
about it. :)

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/16/2007 2:24:02 AM
On Sat, 15 Dec 2007 01:57:57 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> > (Incidentally, is there any way to run a REXX library function
> > through icsdebug or something equivalent?)
> 
> Yeah, just debug CMD.EXE and set a DLL load breakpoint. Then you can set
> other breakpoints in your DLL.

Ah!  Of course!  Thanks.

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/16/2007 2:26:02 AM
In <mdq090pMZSKk-pn2-6mCxzHM9R8Kr@localhost>, on 12/15/2007
   at 08:24 PM, "Alex Taylor" <mail.me@reply.to.address> said:

Hi,

>If you mean the 4OS2 workaround you posted, I added it and it removes the
>crash.  However, it ALWAYS returns non-zero... even when run under PMREXX
>or from a VX-REXX program.  So my function still doesn't work, even if it
>no longer crashes.

Non-zero means success for a Win... function?  Are you sure your function
is not working.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
12/16/2007 4:27:24 AM
On Sun, 16 Dec 2007 04:27:24 UTC, Steven Levine <steve53@earthlink.bogus.net> 
wrote:

> >If you mean the 4OS2 workaround you posted, I added it and it removes the
> >crash.  However, it ALWAYS returns non-zero... even when run under PMREXX
> >or from a VX-REXX program.  So my function still doesn't work, even if it
> >no longer crashes.
> 
> Non-zero means success for a Win... function?  Are you sure your function
> is not working.

Oops.  I assumed from the way the code was arranged... well, 
never mind.  It always returns success, then.  Adjusting for that,
the function still crashes (see below) the moment I try to read 
the contents.


12-16-2007  23:53:48  SYS3175  PID 00b7  TID 0001  Slot 00a1
C:\OS2\CMD.EXE
c0000005
1feb07d5
P1=00000001  P2=146e0000  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=00000005  EBX=18943bfc  ECX=146e0000  EDX=00081036
ESI=00000001  EDI=146e0000  
DS=0053  DSACC=f0f3  DSLIM=ffffffff  
ES=0053  ESACC=f0f3  ESLIM=ffffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1feb07d5  CSACC=f0df  CSLIM=ffffffff
SS:ESP=006b:001ffb58  SSACC=f0f3  SSLIM=ffffffff
EBP=001ffbbc  FLG=00012206

LIBUNI.DLL 0001:000007d5


-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/16/2007 2:57:02 PM
On 16 Dec 2007 08:57:02 -0600, Alex Taylor <mail.me@reply.to.address> wrote:

> 12-16-2007  23:53:48  SYS3175  PID 00b7  TID 0001  Slot 00a1
> C:\OS2\CMD.EXE
> c0000005
> 1feb07d5
> P1=00000001  P2=146e0000  P3=XXXXXXXX  P4=XXXXXXXX  
> EAX=00000005  EBX=18943bfc  ECX=146e0000  EDX=00081036
> ESI=00000001  EDI=146e0000  
> DS=0053  DSACC=f0f3  DSLIM=ffffffff  
> ES=0053  ESACC=f0f3  ESLIM=ffffffff  
> FS=150b  FSACC=00f3  FSLIM=00000030
> GS=0000  GSACC=****  GSLIM=********
> CS:EIP=005b:1feb07d5  CSACC=f0df  CSLIM=ffffffff
> SS:ESP=006b:001ffb58  SSACC=f0f3  SSLIM=ffffffff
> EBP=001ffbbc  FLG=00012206
> 
> LIBUNI.DLL 0001:000007d5

You didn't post which Uni function you're calling. What attributes did
you give to your shared memory request? The above is telling me it failed
on read to address 146e0000, which otherwise seems like a reasonable address
for what you're trying to do. Did your shared memory request return success?
Can you post the latest code? It's very hard guessing all the time.

If you really don't have Theseus available, can you try a DosQueryMem() on
the address and see what that reveals?
0
Paul
12/16/2007 3:14:38 PM
On Sun, 16 Dec 2007 15:14:38 UTC, Paul Ratcliffe 
<abuse@orac12.clara34.co56.uk78> wrote:

> You didn't post which Uni function you're calling. 

The same thing happens with any.  Or if I try to use printf
or access an element directly, the crash occurs in my DLL instead.
In this case, though, I'm pretty sure it was UniStrlen.

> What attributes did you give to your shared memory request? 

On the query?  PAG_READ.  The application that creates it should
be doing so with PAG_WRITE|PAG_COMMIT|OBJ_GIVEABLE (and my other
function does that).


> The above is telling me it failed on read to address 146e0000, which 
>otherwise seems like a reasonable address for what you're trying to 
> do. Did your shared memory request return success?

Yes, if I haven't gotten my logic crossed.


> Can you post the latest code? It's very hard guessing all the time.

    // Make sure the Unicode clipboard format is registered
    hSATbl = WinQuerySystemAtomTable();
    cf_TextUnicode = WinAddAtom( hSATbl, "text/unicode");

    // Initialize the PM API and open the clipboard
    hab = WinInitialize( 0 );
    if ( hab ) {
        ulRC = WinOpenClipbrd( hab );
        if ( ulRC ) {
            // Read Unicode text from the clipboard, if available
            if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab, 
                                                    cf_TextUnicode )) &&
                ( DosGetSharedMem( psuClipText, PAG_READ )))
            {

                // Convert it to the target codepage
                if ( ulTargetCP == 1200 ) {
                    // Target is UCS-2, so return the UniChar array as bytes
 ---->              ulBytes  = UniStrlen( psuClipText ) * sizeof( UniChar );
                    pszFinal = (PSZ) malloc( ulBytes );
                    j = 0;
                    for ( i = 0; i < UniStrlen(psuClipText); i++ ) {
                        pszFinal[j++] = BYTE1FROMUNICHAR( psuClipText[i] );
                        pszFinal[j++] = BYTE2FROMUNICHAR( psuClipText[i] );
                    }
                    if ( ! SaveResultString( prsResult, pszFinal, ulBytes )) 
                    {
                        MAKERXSTRING( *prsResult, "", 0 );
                    }
                    free( pszFinal );
                } else {
                    // Create the UCS-to-target conversion object
                    ulRC = CreateUconvObject( &uconvTarget, ulTargetCP, 0, 
                                              fMap, fPath, usSub );
                    if ( ulRC == ULS_SUCCESS ) {

                        // Convert the string to the target codepage
                        // (Allow up to 4x the length of the Unicode string)
 ---->                  stInLength      = UniStrlen( psuClipText );
                        stOutLength     = stInLength * 4;
                        pszFinal        = (PSZ) malloc( stOutLength + 1 );
                        psuOffset       = psuClipText;
                        pszOffset       = pszFinal;
                        stSubstitutions = 0;
                        memset( pszFinal, 0, stOutLength + 1 );
                        ulRC = UniUconvFromUcs( uconvTarget, 
                                                &psuOffset, 
                                                &stInLength, 
                                                (PVOID *) &pszOffset, 
                                                &stOutLength, 
                                                &stSubstitutions );
                        if ( ulRC == ULS_SUCCESS ) {
                            // Return the final converted string
                            if ( ! SaveResultString( prsResult, pszFinal, 
                                                     strlen(pszFinal) )) {
                                MAKERXSTRING( *prsResult, "", 0 );
                            }
                            UniFreeUconvObject( uconvTarget );
                        } else {
                            // UniUconvFromUcs failed
                            WriteErrorCode( ulRC, "UniUconvFromUcs");
                            MAKERXSTRING( *prsResult, "", 0 );
                        }
                        free( pszFinal );

                    } else {
                        // Failed to create target UconvObject
                        WriteErrorCode( ulRC, "UniCreateUconvObject");
                        MAKERXSTRING( *prsResult, "", 0 );
                    }
                }
            } else {
                // Either no text exists, or clipboard is not readable
                MAKERXSTRING( *prsResult, "", 0 );
            }

            WinCloseClipbrd( hab );
        } else
            WriteErrorCode( ulRC, "WinOpenClipbrd");

        WinTerminate( hab );
    } else
        WriteErrorCode( 0, "WinInitialize");

    WinDeleteAtom( hSATbl, cf_TextUnicode );


Depending on the parameters used, the crash occurs at one of the 
lines marked with '---->', at least as far as I can tell.


> If you really don't have Theseus available, can you try a DosQueryMem() on
> the address and see what that reveals?

I'll take a look.

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/18/2007 8:30:02 AM
[A complimentary Cc of this posting was sent to
Alex Taylor
<mail.me@reply.to.address>], who wrote in article <mdq090pMZSKk-pn2-ewlDYxfbgVS2@localhost>:
> On Sun, 16 Dec 2007 15:14:38 UTC, Paul Ratcliffe 
> <abuse@orac12.clara34.co56.uk78> wrote:
> 
> > You didn't post which Uni function you're calling. 
> 
> The same thing happens with any.  Or if I try to use printf
> or access an element directly, the crash occurs in my DLL instead.
> In this case, though, I'm pretty sure it was UniStrlen.

Junk in, Junk out.  Try reading 1 byte at this address.  Most probably
it is just not a "correct string" (not \0\0-terminated).

In my code to access shared memory buffers, it is done in the
following steps:

 a) Get pointer;
 b) Get memory object size pointed to by this pointer;
 c) Look for end-of-string mark WITHIN the limits of the memory buffer.

Example Perl code:

  # Good for \0-terminated text (not "text/unicode" and other Firefox stuff)
  sub ClipbrdText (@) {
    my $h = OS2::localClipbrd->new;
    my $data = ClipbrdData @_;
    return unless $data;
    my ($lim) = MemoryRegionSize($data);	# List context essential
    $lim = StrLen($data, $lim);			# Look for 1-byte 0
    return unpack "P$lim", pack 'L', $data;
  }

  sub ClipbrdText_2byte (@) {
    my $h = OS2::localClipbrd->new;
    my $data = ClipbrdData @_;
    return unless $data;
    my ($lim) = MemoryRegionSize($data);	# List context essential
    $lim = StrLen($data, $lim, 2);		# Look for 2-byte 0
    return unpack "P$lim", pack 'L', $data;
  }

[Ignore "List context essential"; this is just a bad API design on my side.]

MemoryRegionSize() is done by:

ULONG
QueryMemoryRegionSize(ULONG addr, ULONG *flagp, ULONG len, I32 interrupt)
{
    ULONG l, f;				/* Modifiable copy */
    ULONG rc;

    do {
	l = len;
	rc = DosQueryMem((void *)addr, &l, &f);
    } while ( interrupt ? 0 : rc == ERROR_INTERRUPT );

    /* We assume this is not about addr */
/*
    if (rc == ERROR_INVALID_ADDRESS)
	return 0xFFFFFFFF;
*/
    os2cp_croak(rc,"QueryMemoryRegionSize");
    if (flagp)
	*flagp = f;
    return l;
}

Hope this helps,
Ilya
0
Ilya
12/18/2007 9:18:33 AM
On Tue, 18 Dec 2007 08:30:02 UTC, "Alex Taylor" wrote:
> On Sun, 16 Dec 2007 15:14:38 UTC, Paul Ratcliffe wrote:
> 
> > Can you post the latest code? It's very hard guessing all the time.
> 
>     // Make sure the Unicode clipboard format is registered
>     hSATbl = WinQuerySystemAtomTable();
>     cf_TextUnicode = WinAddAtom( hSATbl, "text/unicode");
> 
>     // Initialize the PM API and open the clipboard
>     hab = WinInitialize( 0 );
>     if ( hab ) {
>         ulRC = WinOpenClipbrd( hab );
>         if ( ulRC ) {
>             // Read Unicode text from the clipboard, if available
>             if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab, 
>                                                     cf_TextUnicode )) &&
>                 ( DosGetSharedMem( psuClipText, PAG_READ )))
>             {
> 
>                 // Convert it to the target codepage
>                 if ( ulTargetCP == 1200 ) {
>                     // Target is UCS-2, so return the UniChar array as bytes
>  ---->              ulBytes  = UniStrlen( psuClipText ) * sizeof( UniChar );
<snip>

1 - Dos functions return 0 if successful or an error code otherwise.  Above,
    your code only proceeds if DosGetSharedMem() *failed*.

2 - This is probably not the cause, but it's worth noting that you should
    call WinInitialize() before using _any_ other PM function.  Adhering to
    "good form" may stave off other problems in future projects.

3 - As Paul suggested, use DosQueryMem() to get the memory's allocation
    flags - but don't forget to check _it's_ return code.  If you get a
    "487 - ERROR_INVALID_ADDRESS", the memory is guaranteed to be unusable.
    (IIRC, this tends to happen when the source is a VIO window.)


-- 
== == almost usable email address:  rws AT e-vertise.com == ==
___________________________________________________________________
                |
                |          Remote Workplace Server v0.80
Rich Walsh      |      interact with the WPS from any program
Ft Myers, FL    |       http://e-vertise.com/rws/rws080.zip
___________________________________________________________________
0
Rich
12/19/2007 1:33:07 AM
On 19 Dec 2007 01:33:07 GMT, Rich Walsh <spamyourself@127.0.0.1> wrote:

>>                 ( DosGetSharedMem( psuClipText, PAG_READ )))

As Rich noted, you have the logic backwards here. On my test, this call
returned error 5 - Access denied...

> 3 - As Paul suggested, use DosQueryMem() to get the memory's allocation
>     flags - but don't forget to check _it's_ return code.

<grumble>
Possessive "its" does not have an apostrophe, but everybody seems to do it
these days :-(
</grumble>

.... and this returns PAG_FREE not surprisingly.

I tried PAG_READ | PAG_WRITE on the shared memory call and it made no
difference. I'm not sure what you do next.
0
Paul
12/19/2007 10:26:02 AM
On Tue, 18 Dec 2007 09:18:33 +0000 (UTC), Ilya Zakharevich
<nospam-abuse@ilyaz.org> wrote:

>> The same thing happens with any.  Or if I try to use printf
>> or access an element directly, the crash occurs in my DLL instead.
>> In this case, though, I'm pretty sure it was UniStrlen.
> 
> Junk in, Junk out.  Try reading 1 byte at this address.  Most probably
> it is just not a "correct string" (not \0\0-terminated).

As has already been established from the trap data, had you bothered to check,
the trap happens at the first byte in the buffer which kinda rules out your
guesswork.
0
Paul
12/19/2007 10:34:14 AM
"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-ewlDYxfbgVS2@localhost...
> On Sun, 16 Dec 2007 15:14:38 UTC, Paul Ratcliffe
> <abuse@orac12.clara34.co56.uk78> wrote:
>
>> You didn't post which Uni function you're calling.
>
> The same thing happens with any.  Or if I try to use printf
> or access an element directly, the crash occurs in my DLL instead.
> In this case, though, I'm pretty sure it was UniStrlen.
>
>> What attributes did you give to your shared memory request?
>
> On the query?  PAG_READ.  The application that creates it should
> be doing so with PAG_WRITE|PAG_COMMIT|OBJ_GIVEABLE (and my other
> function does that).

No, the allocating application should use PAG_READ | PAG_WRITE | PAG_COMMIT 
| OBJ_GETTABLE.

OBJ_GIVEABLE requires the allocator to explicitely grant access to the 
requesting application by use of  DosGiveSharedMem. And PAG_READ is 
necessary so that requester can read.

Lars 


0
Lars
12/25/2007 2:25:24 PM
Hi,

"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-ewlDYxfbgVS2@localhost...
> On Sun, 16 Dec 2007 15:14:38 UTC, Paul Ratcliffe
> <abuse@orac12.clara34.co56.uk78> wrote:
>
>> You didn't post which Uni function you're calling.
>
> The same thing happens with any.  Or if I try to use printf
> or access an element directly, the crash occurs in my DLL instead.
> In this case, though, I'm pretty sure it was UniStrlen.
>
>> What attributes did you give to your shared memory request?
>
> On the query?  PAG_READ.  The application that creates it should
> be doing so with PAG_WRITE|PAG_COMMIT|OBJ_GIVEABLE (and my other
> function does that).

That is wrong, see my other post but if OBJ_GIVEABLE was used then try to 
use DosGiveSharedMem. That should normally be used from the source process 
but maybe, it also works from the target process (at least, the control 
program programming guide does not preclude it):

PPIB ppib=NULL;
if (!DosGetInfoBlocks(NULL, &ppib))
{

    if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab,
                                                      cf_TextUnicode )) &&
    (!DosGiveSharedMem( psuClipText, ppib->pib_ulpid,PAG_READ )))
    {
          ....
     }
     ...
}


>
>
>> The above is telling me it failed on read to address 146e0000, which
>>otherwise seems like a reasonable address for what you're trying to
>> do. Did your shared memory request return success?
>
> Yes, if I haven't gotten my logic crossed.
>
>
>> Can you post the latest code? It's very hard guessing all the time.
>
>    // Make sure the Unicode clipboard format is registered
>    hSATbl = WinQuerySystemAtomTable();
>    cf_TextUnicode = WinAddAtom( hSATbl, "text/unicode");
>
>    // Initialize the PM API and open the clipboard
>    hab = WinInitialize( 0 );
>    if ( hab ) {
>        ulRC = WinOpenClipbrd( hab );
>        if ( ulRC ) {
>            // Read Unicode text from the clipboard, if available
>            if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab,
>                                                    cf_TextUnicode )) &&
>                ( DosGetSharedMem( psuClipText, PAG_READ )))
>            {
>
>                // Convert it to the target codepage
>                if ( ulTargetCP == 1200 ) {
>                    // Target is UCS-2, so return the UniChar array as 
> bytes
> ---->              ulBytes  = UniStrlen( psuClipText ) * sizeof( 
> UniChar );
>                    pszFinal = (PSZ) malloc( ulBytes );
>                    j = 0;
>                    for ( i = 0; i < UniStrlen(psuClipText); i++ ) {
>                        pszFinal[j++] = BYTE1FROMUNICHAR( psuClipText[i] );
>                        pszFinal[j++] = BYTE2FROMUNICHAR( psuClipText[i] );
>                    }
>                    if ( ! SaveResultString( prsResult, pszFinal, 
> ulBytes ))
>                    {
>                        MAKERXSTRING( *prsResult, "", 0 );
>                    }
>                    free( pszFinal );
>                } else {
>                    // Create the UCS-to-target conversion object
>                    ulRC = CreateUconvObject( &uconvTarget, ulTargetCP, 0,
>                                              fMap, fPath, usSub );
>                    if ( ulRC == ULS_SUCCESS ) {
>
>                        // Convert the string to the target codepage
>                        // (Allow up to 4x the length of the Unicode 
> string)
> ---->                  stInLength      = UniStrlen( psuClipText );
>                        stOutLength     = stInLength * 4;
>                        pszFinal        = (PSZ) malloc( stOutLength + 1 );
>                        psuOffset       = psuClipText;
>                        pszOffset       = pszFinal;
>                        stSubstitutions = 0;
>                        memset( pszFinal, 0, stOutLength + 1 );
>                        ulRC = UniUconvFromUcs( uconvTarget,
>                                                &psuOffset,
>                                                &stInLength,
>                                                (PVOID *) &pszOffset,
>                                                &stOutLength,
>                                                &stSubstitutions );
>                        if ( ulRC == ULS_SUCCESS ) {
>                            // Return the final converted string
>                            if ( ! SaveResultString( prsResult, pszFinal,
>                                                     strlen(pszFinal) )) {
>                                MAKERXSTRING( *prsResult, "", 0 );
>                            }
>                            UniFreeUconvObject( uconvTarget );
>                        } else {
>                            // UniUconvFromUcs failed
>                            WriteErrorCode( ulRC, "UniUconvFromUcs");
>                            MAKERXSTRING( *prsResult, "", 0 );
>                        }
>                        free( pszFinal );
>
>                    } else {
>                        // Failed to create target UconvObject
>                        WriteErrorCode( ulRC, "UniCreateUconvObject");
>                        MAKERXSTRING( *prsResult, "", 0 );
>                    }
>                }
>            } else {
>                // Either no text exists, or clipboard is not readable
>                MAKERXSTRING( *prsResult, "", 0 );
>            }
>
>            WinCloseClipbrd( hab );
>        } else
>            WriteErrorCode( ulRC, "WinOpenClipbrd");
>
>        WinTerminate( hab );
>    } else
>        WriteErrorCode( 0, "WinInitialize");
>
>    WinDeleteAtom( hSATbl, cf_TextUnicode );
>
>
> Depending on the parameters used, the crash occurs at one of the
> lines marked with '---->', at least as far as I can tell.
>
>
>> If you really don't have Theseus available, can you try a DosQueryMem() 
>> on
>> the address and see what that reveals?
>
> I'll take a look.
>
> -- 
> Alex Taylor
> http://www.cs-club.org/~alex
>
> Please take off hat when replying. 


0
Lars
12/25/2007 2:43:47 PM
By the way:

what happens if that shared memory was allocated in high address space ? 
Maybe you should also take the OBJ_ANY flag into consideration if you 
request that shared memory. Try without and with the OBJ_ANY flag ...

Lars


"Lars Erdmann" <lars.erdmann@arcor.de> schrieb im Newsbeitrag 
news:477117bc$0$16652$9b4e6d93@newsspool3.arcor-online.net...
> Hi,
>
> "Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
> news:mdq090pMZSKk-pn2-ewlDYxfbgVS2@localhost...
>> On Sun, 16 Dec 2007 15:14:38 UTC, Paul Ratcliffe
>> <abuse@orac12.clara34.co56.uk78> wrote:
>>
>>> You didn't post which Uni function you're calling.
>>
>> The same thing happens with any.  Or if I try to use printf
>> or access an element directly, the crash occurs in my DLL instead.
>> In this case, though, I'm pretty sure it was UniStrlen.
>>
>>> What attributes did you give to your shared memory request?
>>
>> On the query?  PAG_READ.  The application that creates it should
>> be doing so with PAG_WRITE|PAG_COMMIT|OBJ_GIVEABLE (and my other
>> function does that).
>
> That is wrong, see my other post but if OBJ_GIVEABLE was used then try to 
> use DosGiveSharedMem. That should normally be used from the source process 
> but maybe, it also works from the target process (at least, the control 
> program programming guide does not preclude it):
>
> PPIB ppib=NULL;
> if (!DosGetInfoBlocks(NULL, &ppib))
> {
>
>    if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab,
>                                                      cf_TextUnicode )) &&
>    (!DosGiveSharedMem( psuClipText, ppib->pib_ulpid,PAG_READ )))
>    {
>          ....
>     }
>     ...
> }
>
>
>>
>>
>>> The above is telling me it failed on read to address 146e0000, which
>>>otherwise seems like a reasonable address for what you're trying to
>>> do. Did your shared memory request return success?
>>
>> Yes, if I haven't gotten my logic crossed.
>>
>>
>>> Can you post the latest code? It's very hard guessing all the time.
>>
>>    // Make sure the Unicode clipboard format is registered
>>    hSATbl = WinQuerySystemAtomTable();
>>    cf_TextUnicode = WinAddAtom( hSATbl, "text/unicode");
>>
>>    // Initialize the PM API and open the clipboard
>>    hab = WinInitialize( 0 );
>>    if ( hab ) {
>>        ulRC = WinOpenClipbrd( hab );
>>        if ( ulRC ) {
>>            // Read Unicode text from the clipboard, if available
>>            if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab,
>>                                                    cf_TextUnicode )) &&
>>                ( DosGetSharedMem( psuClipText, PAG_READ )))
>>            {
>>
>>                // Convert it to the target codepage
>>                if ( ulTargetCP == 1200 ) {
>>                    // Target is UCS-2, so return the UniChar array as 
>> bytes
>> ---->              ulBytes  = UniStrlen( psuClipText ) * sizeof( 
>> UniChar );
>>                    pszFinal = (PSZ) malloc( ulBytes );
>>                    j = 0;
>>                    for ( i = 0; i < UniStrlen(psuClipText); i++ ) {
>>                        pszFinal[j++] = BYTE1FROMUNICHAR( 
>> psuClipText[i] );
>>                        pszFinal[j++] = BYTE2FROMUNICHAR( 
>> psuClipText[i] );
>>                    }
>>                    if ( ! SaveResultString( prsResult, pszFinal, 
>> ulBytes ))
>>                    {
>>                        MAKERXSTRING( *prsResult, "", 0 );
>>                    }
>>                    free( pszFinal );
>>                } else {
>>                    // Create the UCS-to-target conversion object
>>                    ulRC = CreateUconvObject( &uconvTarget, ulTargetCP, 0,
>>                                              fMap, fPath, usSub );
>>                    if ( ulRC == ULS_SUCCESS ) {
>>
>>                        // Convert the string to the target codepage
>>                        // (Allow up to 4x the length of the Unicode 
>> string)
>> ---->                  stInLength      = UniStrlen( psuClipText );
>>                        stOutLength     = stInLength * 4;
>>                        pszFinal        = (PSZ) malloc( stOutLength + 1 );
>>                        psuOffset       = psuClipText;
>>                        pszOffset       = pszFinal;
>>                        stSubstitutions = 0;
>>                        memset( pszFinal, 0, stOutLength + 1 );
>>                        ulRC = UniUconvFromUcs( uconvTarget,
>>                                                &psuOffset,
>>                                                &stInLength,
>>                                                (PVOID *) &pszOffset,
>>                                                &stOutLength,
>>                                                &stSubstitutions );
>>                        if ( ulRC == ULS_SUCCESS ) {
>>                            // Return the final converted string
>>                            if ( ! SaveResultString( prsResult, pszFinal,
>>                                                     strlen(pszFinal) )) {
>>                                MAKERXSTRING( *prsResult, "", 0 );
>>                            }
>>                            UniFreeUconvObject( uconvTarget );
>>                        } else {
>>                            // UniUconvFromUcs failed
>>                            WriteErrorCode( ulRC, "UniUconvFromUcs");
>>                            MAKERXSTRING( *prsResult, "", 0 );
>>                        }
>>                        free( pszFinal );
>>
>>                    } else {
>>                        // Failed to create target UconvObject
>>                        WriteErrorCode( ulRC, "UniCreateUconvObject");
>>                        MAKERXSTRING( *prsResult, "", 0 );
>>                    }
>>                }
>>            } else {
>>                // Either no text exists, or clipboard is not readable
>>                MAKERXSTRING( *prsResult, "", 0 );
>>            }
>>
>>            WinCloseClipbrd( hab );
>>        } else
>>            WriteErrorCode( ulRC, "WinOpenClipbrd");
>>
>>        WinTerminate( hab );
>>    } else
>>        WriteErrorCode( 0, "WinInitialize");
>>
>>    WinDeleteAtom( hSATbl, cf_TextUnicode );
>>
>>
>> Depending on the parameters used, the crash occurs at one of the
>> lines marked with '---->', at least as far as I can tell.
>>
>>
>>> If you really don't have Theseus available, can you try a DosQueryMem() 
>>> on
>>> the address and see what that reveals?
>>
>> I'll take a look.
>>
>> -- 
>> Alex Taylor
>> http://www.cs-club.org/~alex
>>
>> Please take off hat when replying.
>
> 


0
Lars
12/25/2007 2:48:37 PM
On Tue, 25 Dec 2007 14:25:24 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> No, the allocating application should use PAG_READ | PAG_WRITE | 
> PAG_COMMIT | OBJ_GETTABLE.
> 
> OBJ_GIVEABLE requires the allocator to explicitely grant access to the 
> requesting application by use of  DosGiveSharedMem. And PAG_READ is 
> necessary so that requester can read.

BING!

OK, using that option to write the clipboard data seems to work now,
if my own function is used.

The problem, of course, is that other applications (like Mozilla)
don't necessarily use that flag, and I have no control over them.
Also, they work with each other.  Why doesn't this program?  Is it
because it's a DLL, or running from REXX?

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/26/2007 2:38:02 AM
Hallo,

"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-vG87zY4KY8t9@localhost...
> On Tue, 25 Dec 2007 14:25:24 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> No, the allocating application should use PAG_READ | PAG_WRITE |
>> PAG_COMMIT | OBJ_GETTABLE.
>>
>> OBJ_GIVEABLE requires the allocator to explicitely grant access to the
>> requesting application by use of  DosGiveSharedMem. And PAG_READ is
>> necessary so that requester can read.
>
> BING!
>
> OK, using that option to write the clipboard data seems to work now,
> if my own function is used.
>
> The problem, of course, is that other applications (like Mozilla)
> don't necessarily use that flag, and I have no control over them.
> Also, they work with each other.  Why doesn't this program?  Is it
> because it's a DLL, or running from REXX?

I don't know if I understand your answer correctly but the allocator SHOULD 
do the allocation with OBJ_GIVEABLE because this is the way it is documented 
in the PM Programming Guide and I would assume Mozilla etc. follow that 
track. Sorry, my statement above is therefore wrong.

The thing is, WinGetClipboardData (I assume) should call DosGiveSharedMem 
when it is called from another process (the samples never require or 
indicate that the receiving process needs to call DosGiveSharedMem 
explicitely) but there seems to be a bug that prevents it from doing so if 
it is called from a VIO process.

1.) Mozilla etc. SHOULD use that flag (OBJ_GIVEABLE and NOT OBJ_GETTABLE) 
because in the PM programming guide it is documented to be used when you 
intend to put something into the clipboard. If it still doesn't work you 
will
    a.) need to have a look into the Mozilla sources
    b.) check with Theseus HOW exactly the memory you receive from the 
clipboard is allocated

2.) You never know but I strongly doubt it has anything to do with DLL or 
REXX:
    a.) calling into a DLL is nothing more than an ordinary routine call 
with the difference that the code is located in another module. But the DLL 
routine is executing in the very same process and thread it is called from 
(so there is no context change)

    b.) REXX is just standardizing the DLL interface (for routines 
implemented in a DLL). I don't see any more than that

3.) Have you thought of trying the OBJ_ANY flag in the DosGiveSharedMem call 
? I don't know if it is relevant but I would give it a try.

Lars 


0
Lars
12/26/2007 10:32:09 AM
On Tue, 25 Dec 2007 14:43:47 UTC, "Lars Erdmann" 
<lars.erdmann@arcor.de> wrote:

> PPIB ppib=NULL;
> if (!DosGetInfoBlocks(NULL, &ppib))
> {
> 
>     if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab,
>                                                       cf_TextUnicode )) &&
>     (!DosGiveSharedMem( psuClipText, ppib->pib_ulpid,PAG_READ )))
>     {
>           ....
>      }
>      ...
> }
> 

Excuse me for jumping in, but what is the purpose of the 
DosGiveSharedMem call? Is it belt and braces in case someone has mis 
allocated shared memory when stuffing something *into* the clipboard? 
Because I have never had *any* problems just checking with 
WinQueryClipbrdData for whatever format I need.

TIA
-- 
Regards
Dave Saville

NB Remove nospam. for good email address
0
Dave
12/26/2007 3:50:02 PM
On Wed, 26 Dec 2007 10:32:09 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> The thing is, WinGetClipboardData (I assume) should call DosGiveSharedMem 
> when it is called from another process (the samples never require or 
> indicate that the receiving process needs to call DosGiveSharedMem 
> explicitely) but there seems to be a bug that prevents it from doing so if 
> it is called from a VIO process.
>  
> 1.) Mozilla etc. SHOULD use that flag (OBJ_GIVEABLE and NOT OBJ_GETTABLE) 
> because in the PM programming guide it is documented to be used when you 
> intend to put something into the clipboard. If it still doesn't work you 
> will
>     a.) need to have a look into the Mozilla sources

My logic was originally lifted from Mozilla, so it should be the
same (unless, of course, Mozilla has changed it since then).


>     b.) check with Theseus HOW exactly the memory you receive from the 
> clipboard is allocated

Well, I've installed Theseus now, but I have to confess I don't
actually know how to do this.

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/26/2007 4:36:01 PM
Hallo,

when you look back at the discussion, if you call WinQueryClipbrdData from a 
VIO process (marked as WINDOWCOMPATIBLE), then, for whatever reason, 
WinQueryClipbrdData does not correctly do its job. It returns a valid shared 
memory address but the pointer is not usable (leads to a trap on access).

Lars



"Dave Saville" <dave@nospam.deezee.org> schrieb im Newsbeitrag 
news:fV45K0OBJxbE-pn2-vcP96BH3GONt@localhost...
> On Tue, 25 Dec 2007 14:43:47 UTC, "Lars Erdmann"
> <lars.erdmann@arcor.de> wrote:
>
>> PPIB ppib=NULL;
>> if (!DosGetInfoBlocks(NULL, &ppib))
>> {
>>
>>     if (( psuClipText = (UniChar *) WinQueryClipbrdData( hab,
>>                                                       cf_TextUnicode )) 
>> &&
>>     (!DosGiveSharedMem( psuClipText, ppib->pib_ulpid,PAG_READ )))
>>     {
>>           ....
>>      }
>>      ...
>> }
>>
>
> Excuse me for jumping in, but what is the purpose of the
> DosGiveSharedMem call? Is it belt and braces in case someone has mis
> allocated shared memory when stuffing something *into* the clipboard?
> Because I have never had *any* problems just checking with
> WinQueryClipbrdData for whatever format I need.
>
> TIA
> -- 
> Regards
> Dave Saville
>
> NB Remove nospam. for good email address 


0
Lars
12/27/2007 10:10:16 AM
Hallo,

I am confused now about what works and what does not and if you use 
OBJ_GETTABLE or OBJ_GIVEABLE.

1.) Mozilla etc. should use DosAllocSharedMem(...,NULL,..., PAG_WRITE | 
PAG_COMMIT | OBJ_GIVEABLE) for its memory allocation with the given flags as 
a minimum. This is according to PM Programming Guide. But this is only true 
if it places a pointer into the clipboard (CFI_POINTER). Bitmaps for example 
are handled differently and 3.) does not apply.
2.) Then, calling WinQueryClpbrdData should not cause any problem, but 
obviously it does when it is called from a VIO process
3.) Therefore, the VIO process should call DosGiveSharedMem with its own 
PID. You can also experiment with the OBJ_ANY flag on the DosGiveSharedMem 
call. High memory has introduced some subtleties.

So, how does Mozilla etc. allocate the memory that it places into the 
clipboard ? What Clipboard format does Mozilla use ? I think you should 
precede the call WinQueryClipbrdData with a WinQueryClipbrdFmtInfo call. 
Maybe the format you try to use is wrong. It might make a big difference, 
see 1.)
Also, as Rich suggested, always use WinInitialize/WinTerminate as a bracket 
around any PM functions.

As far as Theseus goes: you need to look around in the linear address view 
(or something like that) as clipboard memory is shared and only appears 
there. Theseus help is good enough to get you rolling.


Send us a piece of your (corrected) code of how you access the clipboard for 
reading from it.

Lars

"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-x8o8zhdVNP8x@localhost...
> On Wed, 26 Dec 2007 10:32:09 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> The thing is, WinGetClipboardData (I assume) should call DosGiveSharedMem
>> when it is called from another process (the samples never require or
>> indicate that the receiving process needs to call DosGiveSharedMem
>> explicitely) but there seems to be a bug that prevents it from doing so 
>> if
>> it is called from a VIO process.
>>
>> 1.) Mozilla etc. SHOULD use that flag (OBJ_GIVEABLE and NOT OBJ_GETTABLE)
>> because in the PM programming guide it is documented to be used when you
>> intend to put something into the clipboard. If it still doesn't work you
>> will
>>     a.) need to have a look into the Mozilla sources
>
> My logic was originally lifted from Mozilla, so it should be the
> same (unless, of course, Mozilla has changed it since then).
>
>
>>     b.) check with Theseus HOW exactly the memory you receive from the
>> clipboard is allocated
>
> Well, I've installed Theseus now, but I have to confess I don't
> actually know how to do this.
>
> -- 
> Alex Taylor
> http://www.cs-club.org/~alex
>
> Please take off hat when replying. 


0
Lars
12/27/2007 10:42:02 AM
On Thu, 27 Dec 2007 10:42:02 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> I am confused now about what works and what does not and if you use 
> OBJ_GETTABLE or OBJ_GIVEABLE.

There's no question that the memory must be allocated as OBJ_GIVEABLE.
Calling WinSetClipbrdData() gives the memory to the shell process
(typically, pmshell #1) which then "owns" it.  Calling WinQueryClipbrdData()
causes the shell process to give the memory to the calling process
(presumably, there's some IPC & a context switch or two needed to
accomplish this).  When you call WinCloseClipbrd(), the memory is
freed for the calling process but not for the shell process.

>You can also experiment with the OBJ_ANY flag on the DosGiveSharedMem call.

Don't even think about using OBJ_ANY:  16-bit apps still need access.

-----

What I have to wonder is whether the process type is causing problems.
For a script invoked from cmd.exe, it's probably 2 (windowable VIO).
Since nothing else seems to help, perhaps changing it to 3 (PM) might
make a difference.  Doing so is easy:

  void    Morph( void)
  {
      PTIB    ptib;
      PPIB    ppib;

      DosGetInfoBlocks( &ptib, &ppib);
      ppib->pib_ultype = 3;
      return;
  }

I use this in PM apps that I've misidentified as VIO so I can get
a console window.  In those apps, there's no reason to restore the
original value;  however, in this case it might be advisable.
Note that the switch to PM should be done before any access to PM
is attempted.

BTW... have you attempted to access clipboard data placed there by
some other app?  IOW, just ask for plain-text and confirm that your
code can read it.  If that works OK, then the problem probably lies
with your code which puts it on the clipboard.



-- 
== == almost usable email address:  rws AT e-vertise.com == ==
___________________________________________________________________
                |
                |          Remote Workplace Server v0.80
Rich Walsh      |      interact with the WPS from any program
Ft Myers, FL    |       http://e-vertise.com/rws/rws080.zip
___________________________________________________________________
0
Rich
12/27/2007 4:48:51 PM
On Thu, 27 Dec 2007 10:10:16 UTC, "Lars Erdmann" 
<lars.erdmann@arcor.de> wrote:

> Hallo,
> 
> when you look back at the discussion, if you call WinQueryClipbrdData from a 
> VIO process (marked as WINDOWCOMPATIBLE), then, for whatever reason, 
> WinQueryClipbrdData does not correctly do its job. It returns a valid shared 
> memory address but the pointer is not usable (leads to a trap on access).
> 
> Lars

In ClipPipe, part of the ClipView suite, that dumps the (text) 
clipboard to STDOUT and is marked WINDOWCOMPATABLE in it's def file, I
start:

DosGetInfoBlocks( &ptib, &ppib);
ppib->pib_ultype = 3;
hab = WinInitialize(0);

No problems then.

-- 
Regards
Dave Saville

NB Remove nospam. for good email address
0
Dave
12/28/2007 10:15:02 AM
On Thu, 27 Dec 2007 16:48:51 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:

> What I have to wonder is whether the process type is causing problems.
> For a script invoked from cmd.exe, it's probably 2 (windowable VIO).
> Since nothing else seems to help, perhaps changing it to 3 (PM) might
> make a difference.  Doing so is easy:
> 
>   void    Morph( void)
>   {
>       PTIB    ptib;
>       PPIB    ppib;
> 
>       DosGetInfoBlocks( &ptib, &ppib);
>       ppib->pib_ultype = 3;
>       return;
>   }

Well, I've tried adding this.  It doesn't help - even after changing
pib_ultype to 3 the same error occurs.

 
> BTW... have you attempted to access clipboard data placed there by
> some other app?  IOW, just ask for plain-text and confirm that your
> code can read it.  If that works OK, then the problem probably lies
> with your code which puts it on the clipboard.

Yes to the first, and just tried the second - attempting to access
CF_TEXT fails with a similar error.

I've thrown together a standalone VIO app that does the same thing; 
the error is the same.
http://www.cs-club.org/~alex/programming/os2/tuclip.zip
if anyone is interested in taking a look.

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/29/2007 4:44:02 AM
On Sat, 29 Dec 2007 04:44:02 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> On Thu, 27 Dec 2007 16:48:51 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:
> 
> > What I have to wonder is whether the process type is causing problems.
> > For a script invoked from cmd.exe, it's probably 2 (windowable VIO).
> > Since nothing else seems to help, perhaps changing it to 3 (PM) might
> > make a difference.  Doing so is easy:
> > 
> >   void    Morph( void)
> >   {
> >       PTIB    ptib;
> >       PPIB    ppib;
> > 
> >       DosGetInfoBlocks( &ptib, &ppib);
> >       ppib->pib_ultype = 3;
> >       return;
> >   }
> 
> Well, I've tried adding this.  It doesn't help - even after changing
> pib_ultype to 3 the same error occurs.

Hi Alex

My make did not like your make file so I just did gcc tuclip.c.

1) You need PAG_READ as well when you alloc shared memory.
2) You need the length +1 in the alloc - you count the trailing NULL.
3) You need a message queue create after win init, destroy before win 
term

HMQ hmq;
hmq = WinCreateMsgQueue(hab, 0);

Then it works with the ppib->pib_ultype = 3 fix and no DosGetSharedMem
call.

HTH
 -- 
Regards
Dave Saville

NB Remove nospam. for good email address
0
Dave
12/29/2007 1:55:48 PM
On Sat, 29 Dec 2007 13:55:48 UTC, "Dave Saville" <dave@nospam.deezee.org> 
wrote:

> My make did not like your make file so I just did gcc tuclip.c.

I use nmake32, should've mentioned it.

 
> 1) You need PAG_READ as well when you alloc shared memory.

I thought PAG_WRITE automatically implies PAG_READ as well...


> 2) You need the length +1 in the alloc - you count the trailing NULL.

The ulBuflen value includes it already.


> 3) You need a message queue create after win init, destroy before win 
> term
> 
> HMQ hmq;
> hmq = WinCreateMsgQueue(hab, 0);
> 
> Then it works with the ppib->pib_ultype = 3 fix and no DosGetSharedMem
> call.

Ah, clever!  I'd assumed it wasn't necessary since I was never using a
HMQ explicitly...

OK, so the standalone app now works.  I'll try and see if the fix 
extends to the DLL now...

Thanks!
-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/29/2007 3:37:02 PM
On Sat, 29 Dec 2007 15:37:02 UTC, "Alex Taylor" 
<mail.me@reply.to.address> wrote:

> > HMQ hmq;
> > hmq = WinCreateMsgQueue(hab, 0);
> > 
> > Then it works with the ppib->pib_ultype = 3 fix and no DosGetSharedMem
> > call.
> 
> Ah, clever!  I'd assumed it wasn't necessary since I was never using a
> HMQ explicitly...
>

ISTR that you get back a WM_DRAWCLIPBOARD or similar - Even though you
wrote it :-) I guess the abend was the message manager trying to post 
to a non existant queue.  
 
> OK, so the standalone app now works.  I'll try and see if the fix 
> extends to the DLL now...
> 
> Thanks!

No problem, glad it works.

-- 
Regards
Dave Saville

NB Remove nospam. for good email address
0
Dave
12/29/2007 6:33:40 PM
On Sat, 29 Dec 2007 18:33:40 UTC, "Dave Saville" <dave@nospam.deezee.org> 
wrote:

> > > HMQ hmq;
> > > hmq = WinCreateMsgQueue(hab, 0);
> > > 
> > > Then it works with the ppib->pib_ultype = 3 fix and no DosGetSharedMem
> > > call.
>  
> > OK, so the standalone app now works.  I'll try and see if the fix 
> > extends to the DLL now...
> > 
> > Thanks!
> 
> No problem, glad it works.

Yup, the DLL works now too, at least with test scripts.  Now to
try using it in a real program... 


-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/30/2007 4:02:02 AM
On Thu, 27 Dec 2007 10:42:02 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> As far as Theseus goes: you need to look around in the linear address view 
> (or something like that) as clipboard memory is shared and only appears 
> there. Theseus help is good enough to get you rolling.
 
Well, I tried several views, but in all of them it reported that the
address I was getting back didn't exist.

  
> Send us a piece of your (corrected) code of how you access the clipboard 
> for reading from it.

Same URL as before, I've fixed the sample program so it now works.
http://www.cs-club.org/~alex/programming/os2/tuclip.zip  


-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
12/31/2007 4:15:04 PM
BTW - Warpzilla writes unicode clips - which your test case can read. 
But, it also writes an ASCII CF_TEXT version which yours does not. Of 
course you may be doing that in the actual application.

-- 
Regards
Dave Saville

NB Remove nospam. for good email address
0
Dave
12/31/2007 6:14:28 PM
On Mon, 31 Dec 2007 18:14:28 UTC, "Dave Saville" <dave@nospam.deezee.org> 
wrote:

> BTW - Warpzilla writes unicode clips - which your test case can read. 
> But, it also writes an ASCII CF_TEXT version which yours does not. Of 
> course you may be doing that in the actual application.

Yeah, my current instinct is that the DLL function should write the
one clipboard format only, and leave it up to the application to
do things like empty the clipboard and write other formats that it 
desires.  tuclip is just a simulation of what the DLL function does, 
although I added a WinEmptyClipboard() to reduce confusion in testing.

(This does beg the question of _how_ a REXX application will empty
the clipboard on its own, since AFAIK there's no way of doing so in 
the standard REXX library.  I'm going to think about it some more.)

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/2/2008 1:55:04 AM
 > (This does beg the question of _how_ a REXX application will empty
 > the clipboard on its own
 
"REM | CLIP" / "TYPE EMPTY.TXT > CLIP"?

 > AFAIK there's no way of doing so in the standard REXX library.
 
I don't mind having (Sys)Clip*() added to it, once in a while it
may save a few manual operations and a temporary file. When the
content is e.g. stored in a Rexx stem and the data is no longer
needed, being able to delete it after a successfull import seems
a very reasonable feature to me. It even isn't that OS-specific.



---
0
spamgate
1/2/2008 8:11:27 AM
Hi,

ok, now we know that we basically need a PM app to read from clipboard. By 
the way: my experience is, if you start off a prog as VIO and subsequently 
morph to PM (as your sample does), there is no need for intermediate 
switches to VIO in order to output something via printf. If it started off 
as VIO then stdout and stderr are always available, just as much as a 
console window. Therefore your routine "MorphOutput" is not necessary.

Lars

"Alex Taylor" <mail.me@reply.to.address> schrieb im Newsbeitrag 
news:mdq090pMZSKk-pn2-Ye8Qx0c18eZm@localhost...
> On Thu, 27 Dec 2007 10:42:02 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> 
> wrote:
>
>> As far as Theseus goes: you need to look around in the linear address 
>> view
>> (or something like that) as clipboard memory is shared and only appears
>> there. Theseus help is good enough to get you rolling.
>
> Well, I tried several views, but in all of them it reported that the
> address I was getting back didn't exist.
>
>
>> Send us a piece of your (corrected) code of how you access the clipboard
>> for reading from it.
>
> Same URL as before, I've fixed the sample program so it now works.
> http://www.cs-club.org/~alex/programming/os2/tuclip.zip
>
>
> -- 
> Alex Taylor
> http://www.cs-club.org/~alex
>
> Please take off hat when replying. 


0
Lars
1/2/2008 2:40:22 PM
On Wed, 2 Jan 2008 08:11:27 UTC, spamgate@hotmai1.com (ML) wrote:

>  > (This does beg the question of _how_ a REXX application will empty
>  > the clipboard on its own
>  
> "REM | CLIP" / "TYPE EMPTY.TXT > CLIP"?

I don't see how that would work.  Is "CLIP" even a defined device?

 
>  > AFAIK there's no way of doing so in the standard REXX library.
>  
> I don't mind having (Sys)Clip*() added to it, once in a while it
> may save a few manual operations and a temporary file. When the
> content is e.g. stored in a Rexx stem and the data is no longer
> needed, being able to delete it after a successfull import seems
> a very reasonable feature to me. It even isn't that OS-specific.

Sure, but again, that should go through oorexx.org so it can be
discussed in a cross-platform context.

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/4/2008 11:08:02 PM
On Wed, 2 Jan 2008 14:40:22 UTC, "Lars Erdmann" <lars.erdmann@arcor.de> wrote:

> ok, now we know that we basically need a PM app to read from clipboard. By 
> the way: my experience is, if you start off a prog as VIO and subsequently 
> morph to PM (as your sample does), there is no need for intermediate 
> switches to VIO in order to output something via printf. If it started off 
> as VIO then stdout and stderr are always available, just as much as a 
> console window. Therefore your routine "MorphOutput" is not necessary.

But printf() didn't seem to work without it...

-- 
Alex Taylor
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/4/2008 11:11:02 PM
On 4 Jan 2008 17:11:02 -0600, Alex Taylor <mail.me@reply.to.address> wrote:

>> ok, now we know that we basically need a PM app to read from clipboard. By 
>> the way: my experience is, if you start off a prog as VIO and subsequently 
>> morph to PM (as your sample does), there is no need for intermediate 
>> switches to VIO in order to output something via printf. If it started off 
>> as VIO then stdout and stderr are always available, just as much as a 
>> console window. Therefore your routine "MorphOutput" is not necessary.
> 
> But printf() didn't seem to work without it...

In the test program that I did, after creating the message queue, I put the
process type back to what it was before. You don't need it set to PM for
anything else AFAIK. printf() worked fine.
0
Paul
1/5/2008 12:25:47 AM
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Lars Erdmann
<lars.erdmann@arcor.de>], who wrote in article <477ba255$0$17535$9b4e6d93@newsspool4.arcor-online.net>:
> Hi,
> 
> ok, now we know that we basically need a PM app to read from clipboard. By 
> the way: my experience is, if you start off a prog as VIO and subsequently 
> morph to PM (as your sample does), there is no need for intermediate 
> switches to VIO in order to output something via printf. If it started off 
> as VIO then stdout and stderr are always available, just as much as a 
> console window. Therefore your routine "MorphOutput" is not necessary.

My experience is kinda "mixed".  Some time in the past I saw some need
to switch back to VIO-type: without it DosOpen()ing the file /dev/con
would not work "as expected".  But more recently, I reran the tests,
and I could open /dev/con with PM-type without any problem.

Might have been some fixpak/upgrade which changed this; or maybe the
tests were subtly botched...  In short: nowadays, I know no case when
having VIO-type is beneficial...

Yours,
Ilya
0
Ilya
1/5/2008 4:25:57 AM
 >>> (This does beg the question of _how_ a REXX application will
 >>> empty the clipboard on its own

 >> "TYPE EMPTY.TXT > CLIP"?

 > I don't see how that would work.

It doesn't now. "EMPTY.TXT" has to be larger than 0 bytes, but with
1 byte in it "CLIP < EMPTY.TXT" works fine. So: near empty, as-is.

 > Is "CLIP" even a defined device?
 
"CLIP" has been referred to earlier in this thread. I don't know the
background of your question, but if one needs a way to empty it with
Rexx, the "CLIP"-Usenet example referred to and the above may help.

 > Sure, but again, that should go through oorexx.org so it can be
 > discussed in a cross-platform context.
 
ooRexx, not a real .org, is "managed" by the RexxLA. The RexxLA has
nothing to do with any cross-platform context. It's not their goal,
they don't have any standard, almost all of the newer functions in
RexxUtil.DLL already shows smart naming conventions nor portability
was ever kept in mind, the RexxLA does nothing related to OS/2, the
language itself has no standard, and a Rexx DLL can be as platform-
specific as you like. The RexxLA may not be what you think it is.
Think about Windows and (wishes of) users, not about cross-platform
contexts. The RexxLA had and has nothing to do with that. Instead of
only accepting the project including the OS/2-version, they dropped
that because IBM's Object Rexx for Windows fullfilled their needs.
I don't care about that, it's not my mistake and I've nothing to do
with that, but it's hard to find a single reason why the RexxLA is
an organization representing a standard somehow.

Nevertheless both of us already showed more cross-platform awareness
than RexxLA's ooRexx-project, despite a lack of RexxLA-activity. I
don't think there's a reason to refuse a discussion participation of
the RexxLA, but it seems to me the RexxLA isn't what you think it
is. And if the process includes a RexxLA-controlled discussion, the
discussion may actually just slow down of stop developments. This
is what RexxLA produces: SysIsFileCompressed(). This isn't what
RexxLA does: SysIsFileNTFSCompressed(), SysWinIsFileCompressed().

I'll state it again: what should SysIsFileCompressed('Backup.ZIP')
return? Whatever they do (so far), I don't really care, but there's
no sign of a cross-platform context (nor awareness) at all, and the
RexxLA doesn't even have a standard. I assume The RexxLA discusses
a 64-bit version of ooRexx for Windows more often than anything we
care about. And if that version would become unportable, they don't
care. We're on our own, and there's hardly a reason to develop with
'em, controlled by the RexxLA that is. I do understand what you're
saying, and I'm happy with about any wise words, but as long as the
RexxLA basicly is doing nothing, I see no reason to let 'em control
anything at all, perhaps unless one likes to be neglected. And why
cannot the situation be reversed, instead of us following them (for
reasons unknown to me)? Like I said before: the newer functions are
hardly portable/usable as-is with any debate, so why call that the
leader? The RexxLA isn't what one thinks it is, and they also don't
claim to be in control of standards. ooRexx itself isn't a standard
which IRL basicly means: we do whatever pleases us, e.g. focussing
at OLE-development instead of our fine cross-platform context. If
you want to share something theoretically in the Rexx-world, you'll
have to think ANSI committees instead of the RexxLA. And we perhaps
already have Rexx API's as a result of that, it's there to use and
the RexxLA has nothing to do with that. They are just calling their
own shots, not ours, just like you're on your own when attempting
to port ooRexx to OS/2. Such RexxLA-activities don't exist. RexxLA
isn't what you may think it is, and the RexxLA also doesn't claim
to be the organization you'll have to invite to a discussion. It's
not a goal nor task of the RexxLA. Uou're on your own, unless you
happen to use a product of a RexxLA-project. RexxUtil.DLL for OS/2
isn't a RexxLA-project, and OS/2 isn't part of their cross-platform
context too. If it was, an OS/2's SysIsFileCompressed('Backup.WPI')
wouldn't have to return a bogus result, but some FS-bit probably
was important enough to claim a generic function name. There's no
cross-platform context kept in mind there, isn't it?

And an already mentioned example of a shared API is the function
SysGetFileDateTime(). If some standard for naming conventions was
kept in mind, SysFileGetDateTime() should have been used instead.
Not because I prefer that, but because of the SysFile*()-group. It
can be added using 2 function names, one for portability, but the
worst one has to be included forever then. Once released, there's
hardly a point-of-return, so the "damage" is already done. One has
to be very carefull, in a way you're showing that too, but IRL such
care isn't applied by this "ooRexx.org". So why ask them? "Wait for
us, we're the leader"? I don't think so, but I'm also not rejecting
anybody's good input and wise words because of (lack of) activities
in the past. But I prefer an OS/2-discussion, if any, above RexxLA.

They have nothing to do with this, and we have nothing to do with
the RexxLA. Yes, both sides could talk with eachother. That would
be a new agenda item for the RexxLA, but it may happen and talking
doesn't matter anyway. But please keep in mind that your goal isn't
the goal of the RexxLA! So what's the goal of discussing anything
with the RexxLA then? They don't really care about cross-platform
contexts at all, at least not up to now, and they don't have means
to achieve such a goal (e.g. the fact that they have no standards,
which was an ANSI committee instead of some RexxLA initiative). The
RexxLA isn't what you think it is, despite the name of the "A", and
ooRexx isn't really an ".org".



---
0
spamgate
1/5/2008 7:34:21 AM
 > Some time in the past I saw some need to switch back to VIO-type
 
Doesn't remaining a PM app mean "having to" serve the MsgQueue,
which could be an "ignorable" issue when PM'ing it for just a few
(milli-) seconds?

And regardless of printf(), other apps/functions/DLLs may depend
on a valid setting too. E.g. opening a file dialog when PM-without-
arg, but a printf()'ed error message when VIO-without-arg, based
on the current setting.



---
0
spamgate
1/5/2008 9:39:17 AM
 > One has to be very carefull, in a way you're showing that too,
 > but IRL such care isn't applied by this "ooRexx.org".

IOW, it's just an example: when adding some (Sys)Clip*()-family of
functions, we already may know OS/2 isn't the only OS with such a
clipboard. Keeping that in mind, perhaps we could virtually agree
that Sys_OS2_Clip*() isn't a good naming convention. Next the way
it works could be designed bad, but on average I'ld rate the OS/2
community's programming skills higher than just ooRexx programmers,
so I hope I'll get flamed _if_ I would propose a crappy function. I
don't see an added value of/role for the RexxLA here by default, if
the RexxLA is willing to suddenly start calling OS/2-shots in the
first place. The Rexx API is "standard", we could do with it what
we want, we probably don't want yet another Reginald again, and I
think we're quite aware of any cross-platform context, even if the
other (far smaller, w.r.t. Rexx!) communities aren't showing that
awareness. 



---
0
spamgate
1/5/2008 10:49:10 AM
[A complimentary Cc of this posting was sent to
ML
<spamgate@hotmai1.com>], who wrote in article <FB1fHlQNAFNT090yn@hotmai1.com>:
> 
>  > Some time in the past I saw some need to switch back to VIO-type
>  
> Doesn't remaining a PM app mean "having to" serve the MsgQueue,

AFAIK, no - if you call CancelShutdown.

> which could be an "ignorable" issue when PM'ing it for just a few
> (milli-) seconds?

You can't do it in a few milliseconds.  Morphing is a very long
process.  (I think a few large DLLs are loaded, etc...)

> And regardless of printf(), other apps/functions/DLLs may depend
> on a valid setting too. E.g. opening a file dialog when PM-without-
> arg, but a printf()'ed error message when VIO-without-arg, based
> on the current setting.

(yes, panic() [sp?] of EMX does this) Since both PM and VIO are "valid
settings", I do not see a problem with this...

Hope this helps,
Ilya
0
Ilya
1/5/2008 7:27:54 PM
 > Are you saying that as long as we support the ANSI 1996 version of
 > Rexx (OS/2 classical Rexx), everything else past that is our own
 > to do?
 
No, and IIRC the only ANSI-compliant Rexx interpreter is Regina. On
its own, ANSI Rexx is not an issue here because there's no standard
w.r.t. (platform-sepcific) RexxUtil.DLLs (nor Object Rexx). It's up
to us to keep any possible design issue in mind, albeit then what's
"us" (you're referring to that below too)?

 > Have you ask for a copy of the sources that IBM provided, since
 > you are down on RexxLA vis portability?
 
AFAIK ooRexx is IBM's commercial Object Rexx plus a few features,
minus e.g. the IDE. IBM's product was also not aimed at OS'es not
covered. But after the transfer of the now freely available sources
to the author/maintainer of a(n) (O)Rexx interpreter, functions are
added to RexxUtil.DLL which still don't show awareness related to
a cross-platform context. I already mentoined a specific example:
what should the FS-specific SysIsFileCompressed('MyBackup.WPI')
return?

 > Have you asked IBM itself, if RexxLA refuses?
 
AFAICT RexxLA didn't refuse. The only selfish-related "blame" could
be that they accepted the Windows-version without including an OS/2
version in their deal too. But that's not a true blame, why should
they care that much about us, when handed a beautifull present. An
maybe asking for (additional, older) sources belongs to porting
(o)(O)Rexx, what (if needed) already should be covered by Adrian's
sourceforge-ooRexx project.

Anyway, please note the RexxLA isn't the Guardian Angel of Rexx. I
don't know why the RexxLA has to be consulted and/or involved. We
still may have the biggest pc-based installed base and user base of
(O)Rexx, it's not a goal nor role of the RexxLA to control versions
of RexxUtil.DLL, and in a way it's just the author of "a" (O)Rexx
interpreter. I don't mind any sane input nor talking, but they are
not in the driver's seat as such. It's our Rexx API, and we can do
with it what we like to do with it. Despite of that, I don't mind
to keep e.g. Alex's cross-platform context in mind, and the same
goes for a smart design. For one to avoid to have to include some
bad design choices forever, due to backwards compatibility.

 > I would not mind kicking in a few bucks to register an
 > organization and get a domain name, if that would help.
 
I don't know where this belongs. The problem could be that we don't
have a natural forum/organization. Where can I e.g. propose changes
without adding those changes myself to some uncontrolled release of
RexxUtil.DLL? No matter what, I consider it to be a part of the OS,
it's "the" Rexx DLL. Without enough care, it's just "yet another
Rexx DLL", which would making "open sourcing" it useless.

 > Then we could see if Adrin (Netlabs) would host web site for it.

As long as counting download isn't more important that availability
at e.g. Hobbes, and a Netlabs-project can embed an "organization",
Netlabs indeed may cover many needs. Including inviting RexxLA to
join such an "unofficial standardization committee", if needed.

 > We should then ask the Linux people if they may be interested in
 > an open source version. Email me directly if you want to go in
 > this direction.
 
You certainly don't need my "permission" to perform whatever smart
move, and if one thinks it's better to include others earlier, it's
fine with me too. I'm not calling the shots, I just identified that
RexxUtil.DLL is an updatable part of the OS or ooRexx. What I did
so far is basicly having written some functions not yet covered by
others (i.e. Greene, IBM's toolkit source code, Suri). It includes
the latest version of our ORexxUtil.DLL, and anyhing portable from
the RexxLA-version. Additionally I may have a few proposals, e.g.
supporting SysPi() as-is, but continue to use some Math*-()-group
instead. So SysPi() for compatibility, but e.g. MathPi() to divide
a larger library in overviewable parts. I already referred to that
as a "spreadsheet functions-like" categorization, and I'ld like to
see more (both "classic" and new) functionality added to it. That
may include improving existing functions too. While keeping other
(possible) platforms in mind, there's no need to ignore that. The
only thing I maybe disagree with so far is that the RexxLA should
be consulted, and I already explained why. They have no standards,
the RexxLA has no such goal nor role, the RexxLA isn't claiming to
have such a goal or role, and the RexxLA hasn't shown being aware
of other OS'es (not covered by the existing ooRexxes, that is). The
RexxLA isn't the Guardian Angel of the Rexx language. Perhaps they
should be that, but they ain't, and have maybe become the author of
(mainly) a Windows Rexx interpreter. They'll discuss OLE far more
often than anything related to e.g. OS/2's Rexx or Rexx in general.

We're in control here, not the RexxLA. I don't mind discussing any
issue with any sane organization, but IMO nowadays the RexxLA isn't
the natural organization to be assumed to be in "the" driver's seat
of our Rexx versions. IRL ooRexx actually stopped Regina/2, so OS/2
isn't and wasn't a RexxLA-priority, despite the great name of the
Association. I also remember that the status of ooRexx/2 couldn't
be viewed with "the" OS/2 webbrowser back then. They don't really
care (enough), and have nothing to do with OS/2's versions. That's
basicly why I disagree with having to consult the RexxLA, assuming
goals and roles not expressed by the RexxLA.



---
0
spamgate
1/6/2008 10:42:06 AM
Sir;

ML wrote:
>  > One has to be very carefull, in a way you're showing that too,
>  > but IRL such care isn't applied by this "ooRexx.org".
> 
> IOW, it's just an example: when adding some (Sys)Clip*()-family of
> functions, we already may know OS/2 isn't the only OS with such a
> clipboard. Keeping that in mind, perhaps we could virtually agree
> that Sys_OS2_Clip*() isn't a good naming convention. Next the way
> it works could be designed bad, but on average I'ld rate the OS/2
> community's programming skills higher than just ooRexx programmers,
> so I hope I'll get flamed _if_ I would propose a crappy function. I
> don't see an added value of/role for the RexxLA here by default, if
> the RexxLA is willing to suddenly start calling OS/2-shots in the
> first place. The Rexx API is "standard", we could do with it what
> we want, we probably don't want yet another Reginald again, and I
> think we're quite aware of any cross-platform context, even if the
> other (far smaller, w.r.t. Rexx!) communities aren't showing that
> awareness. 
> 

Are you saying that as long as we support the ANSI 1996 version of Rexx
(OS/2 classical Rexx), everything else past that is our own to do?  Have
you ask for a copy of the sources that IBM provided, since you are down
on RexxLA vis portability?  Have you asked IBM itself, if RexxLA
refuses?  I would not mind kicking in a few bucks to register an
organization and get a domain name, if that would help.  Then we could
see if Adrin (Netlabs) would host web site for it.  We should then ask
the Linux people if they may be interested in an open source version.
Email me directly if you want to go in this direction.
-- 
Bill
Thanks a Million!
0
William
1/6/2008 11:10:23 AM
 > Since both PM and VIO are "valid settings", I do not see a
 > problem with this...
 
The setting may be "valid", but may no longer represent a default
situation. It's possible that a VIO app morphes into a PM app, and
another component may stop working because VIO is required. So I
always tend to restore to the previous, assumed original situation
when a morph is no longer needed for my part.



---
0
spamgate
1/6/2008 12:15:43 PM
[A complimentary Cc of this posting was sent to
ML
<spamgate@hotmai1.com>], who wrote in article <vZMgHlQNApwJ090yn@hotmai1.com>:
> The setting may be "valid", but may no longer represent a default
> situation. It's possible that a VIO app morphes into a PM app, and
> another component may stop working because VIO is required.

As I said, with current kernel I know no situation when "VIO is
required".

> So I always tend to restore to the previous, assumed original
> situation when a morph is no longer needed for my part.

Me too.  But morphing is very slow, and I always want to reconsider
this decision.  ;-)

Hope this helps,
Ilya
0
Ilya
1/6/2008 9:31:47 PM
ML wrote:
>   >  Have you asked IBM itself, if RexxLA refuses?
>
> AFAICT RexxLA didn't refuse. The only selfish-related "blame" could
> be that they accepted the Windows-version without including an OS/2
> version in their deal too. But that's not a true blame, why should
> they care that much about us, when handed a beautifull present. An
> maybe asking for (additional, older) sources belongs to porting
> (o)(O)Rexx, what (if needed) already should be covered by Adrian's
> sourceforge-ooRexx project.
>
IBM flat cold refused to give REXXLA the OS/2 REXX code.  Members of 
REXXLA in charge of transfer of code from IBM did try to get IBM to 
release the OS/2 specific code but it was owned by a different group 
than what owned the OOREXX that was released and that group would not 
release it.
Andy

0
Andy
1/7/2008 2:08:14 AM
On Sat, 5 Jan 2008 07:34:21 UTC, spamgate@hotmai1.com (ML) wrote:

>  > Sure, but again, that should go through oorexx.org so it can be
>  > discussed in a cross-platform context.
>  
> ooRexx, not a real .org, is "managed" by the RexxLA. The RexxLA has
> nothing to do with any cross-platform context. It's not their goal,
> they don't have any standard, almost all of the newer functions in
> RexxUtil.DLL already shows smart naming conventions nor portability
> was ever kept in mind, the RexxLA does nothing related to OS/2, the
> language itself has no standard, and a Rexx DLL can be as platform-
> specific as you like. The RexxLA may not be what you think it is.
> Think about Windows and (wishes of) users, not about cross-platform
> contexts. The RexxLA had and has nothing to do with that. Instead of
> only accepting the project including the OS/2-version, they dropped
> that because IBM's Object Rexx for Windows fullfilled their needs.
> I don't care about that, it's not my mistake and I've nothing to do
> with that, but it's hard to find a single reason why the RexxLA is
> an organization representing a standard somehow.

--snip--

That's not quite what I meant.  I'm not suggesting we go asking 
RexxLA for permission or anything like that.  In fact, RexxLA
isn't even particularly relevant to what I was saying.

My point is twofold.  First, like it or not, Open ObjectREXX is
the closest thing there is to an open standard for REXX language
design going into the future.  So any work we do to extend REXX
should at least be made available through the same channel.  (In
other words, we should tell them what we're doing, and if possible
get our work hosted, or at least linked, on the same website.)

Second, there's an (IMO) unfortunate trend (as you point out) 
towards cross-platform divergence in REXXUTIL.  Rather than 
simply going along with that, I think we all should do what we
can to try and encourage a reversal of the trend.  Again, that
means telling other platform groups what we're doing, and maybe
getting some discussions going about the best way of designing
APIs to make them portable.

I just don't want us to jump on our horse and ride off without
due consideration for portability.  The more care we put into
that beforehand, the less developers will have reason to curse
us as they try to migrate their programs from one OS to another.

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/9/2008 10:49:02 AM
Sir:

Alex Taylor wrote:
> On Sat, 5 Jan 2008 07:34:21 UTC, spamgate@hotmai1.com (ML) wrote:
> 
>>  > Sure, but again, that should go through oorexx.org so it can be
>>  > discussed in a cross-platform context.
>>  
>> ooRexx, not a real .org, is "managed" by the RexxLA. The RexxLA has
>> nothing to do with any cross-platform context. It's not their goal,
>> they don't have any standard, almost all of the newer functions in
>> RexxUtil.DLL already shows smart naming conventions nor portability
>> was ever kept in mind, the RexxLA does nothing related to OS/2, the
>> language itself has no standard, and a Rexx DLL can be as platform-
>> specific as you like. The RexxLA may not be what you think it is.
>> Think about Windows and (wishes of) users, not about cross-platform
>> contexts. The RexxLA had and has nothing to do with that. Instead of
>> only accepting the project including the OS/2-version, they dropped
>> that because IBM's Object Rexx for Windows fullfilled their needs.
>> I don't care about that, it's not my mistake and I've nothing to do
>> with that, but it's hard to find a single reason why the RexxLA is
>> an organization representing a standard somehow.
> 
> --snip--
> 
> That's not quite what I meant.  I'm not suggesting we go asking 
> RexxLA for permission or anything like that.  In fact, RexxLA
> isn't even particularly relevant to what I was saying.
> 
> My point is twofold.  First, like it or not, Open ObjectREXX is
> the closest thing there is to an open standard for REXX language
> design going into the future.  So any work we do to extend REXX
> should at least be made available through the same channel.  (In
> other words, we should tell them what we're doing, and if possible
> get our work hosted, or at least linked, on the same website.)
> 
> Second, there's an (IMO) unfortunate trend (as you point out) 
> towards cross-platform divergence in REXXUTIL.  Rather than 
> simply going along with that, I think we all should do what we
> can to try and encourage a reversal of the trend.  Again, that
> means telling other platform groups what we're doing, and maybe
> getting some discussions going about the best way of designing
> APIs to make them portable.
> 
> I just don't want us to jump on our horse and ride off without
> due consideration for portability.  The more care we put into
> that beforehand, the less developers will have reason to curse
> us as they try to migrate their programs from one OS to another.
> 
If we are going to tip our hats towards cross-platform compatibility,
then we need to at least have a version of the source that compiles on
Linux (which I suggest because of its low cost of acquiring tools).
This includes all Rexx dlls that we offer, no?
-- 
Bill
Thanks a Million!
0
William
1/9/2008 1:43:12 PM
On Wed, 9 Jan 2008 10:49:02 UTC, "Alex Taylor" <mail.me@reply.to.address> wrote:

> Second, there's an (IMO) unfortunate trend (as you point out) 
> towards cross-platform divergence in REXXUTIL.  Rather than 
> simply going along with that, I think we all should do what we
> can to try and encourage a reversal of the trend.  Again, that
> means telling other platform groups what we're doing, and maybe
> getting some discussions going about the best way of designing
> APIs to make them portable.
> 
> I just don't want us to jump on our horse and ride off without
> due consideration for portability.  The more care we put into
> that beforehand, the less developers will have reason to curse
> us as they try to migrate their programs from one OS to another.

This is all perfectly absurd.  Who in their right mind would use
REXX as a cross-platform scripting language?  On a Top Ten list,
REXX would come in at #11.

There are only two constituencies for REXX on the PC:  OS/2 users
and former mainfamers who now use Windows.  Each group has its own
parochial concerns that are not, and need not, be relevant to the
other.  The only meaningful compatibility issue is preserving REXX's
grammar & syntax so users' basic skill sets remain portable - and
that's not within the scope of the current discussion.

RexxUtil is a library of *platform-specific* functions.  It exists
to serve the needs of OS/2, not Windows or Linux (or MVS for that
matter).  This is how rexx.inf describes it:

  RexxUtil [...] provides the OS/2 REXX programmer with many versatile
  functions.  Primarily, these functions deal with the following:
    OS/2 system commands. 
    User or text screen input/output (I/O). 
    OS/2 INI file I/O. 

Note the emphasis on _O_S_/_2_...

Amidst all the verbiage I've waded through, I've yet to see anyone
propose new functions that would be genuinely useful to OS/2 users.
At the top of _my_ list would be a wrapper for WinReplaceObjectClass(),
the lack of which makes REXX unusable for some WPS-related tasks.

BTW... who the hell needs SysPi ???


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |      New!  DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
1/9/2008 3:59:26 PM
 > Amidst all the verbiage I've waded through, I've yet to see
 > anyone propose new functions that would be genuinely useful
 > to OS/2 users.

It already seems that API fuctions returning anything that could be
usefull/readable by a human is an exhausted resource. Please note
access to all APIs perhaps is a better idea then, already in use by
a few Rexx interpreters.

 > BTW... who the hell needs SysPi ???

And perhaps the same goes for C's functions, e.g. cos(). But it may
be more usefull to integrate e.g. RexxMath.DLL into RexxUtil.DLL to
get rid of a few good YetAnotherRexxDLLs. A library of libraries in
a certain way, without going nuts with such a concept.

W.r.t. SysPi(), I don't think the Rexx "NUMERIC DIGITS 500"-power
is truely used. If you want to add SysPi() (for reasons unknown to
me too, but that already happened in a one-way manner), I'ld prefer
to let SysPi() from now on point to e.g. MathPi() and grab a higher
precision-version of pi() from e.g. snippets.org to support a more
accurate "MathPi(Digits())" instead of a fixed "#define PI 3.14". I
think [Sys|Math]Pi(Digits()) matches Rexx's qualities far better,
albeit I don't crunch numbers using Rexx myself.



---
0
spamgate
1/9/2008 9:32:53 PM
 > This is how rexx.inf describes it:

 > RexxUtil [...] provides the OS/2 REXX programmer with many versatile
 > functions.  Primarily, these functions deal with the following:
 > OS/2 system commands. 
 > User or text screen input/output (I/O). 
 > OS/2 INI file I/O. 

 > Note the emphasis on _O_S_/_2_...
 
It's our REXXSAA.H, and we could do with it whatever pleases us.
The RexxLA has nothing to do with OS/2, Rexx, nor standards, but
despite those minor issues one could talk with this author of a
(mainly) Windows-aimed Rexx interpreter. Given that, in a nutshell,
we can probably talk about (better) naming conventions, (quality
of) API (design) and/or (not) assume SysBrowser() always works
with e.g. the fine Internet Exploder. We can talk with eachother,
we can look at eachother, we can also keep other platforms in mind
as much as reasonably possible (has ooRexx.org ever done that?),
but I'ld rather let OS/2's (or Linux's) SysIsFileCompressed()
return a bogus "FALSE" instead of following the assumed leaders
by adding every bloody file compression algorithm to keep in touch
with some FS-bit of a specific OS, probably once added on request
of "the" user or because one discovered the API returned a human
readable result (with a extremely limited use, I assume).

IRL that doesn't differ that much from e.g. Alex's (shared!) POV,
the main difference being that the RexxLA IMO has nothing to do
with OS/2, never really cared about OS/2 since they "moved on",
and as nothing to do with Rexx's developments nor standards. If
"the" user wants something added, they've probably added it.

I think of (a good) RexxUtil.DLL (and Rexx.INF too) to be a part
of our OS, without some (new!) hosting role for the RexxLA. We've
got the OS, we've got Hobbes for those still running Warp, and
w.r.t. hosting I don't prefer RexxLA.org above Taylor-made.com
(because both have nothing to do with OS/2, perhaps it's a bit
like asking microsoft.com to host ecomstation.com because there's
some remote connection).

Yes, we can (and obviously should) keep anything smart in mind
and/or discuss anything, but we're on our own. Not to mention
our far larger pc-based installed base and user base, despite a
few former OS/2-users have "moved on" towards the former IBM's
Object Rexx for Windows. BTW, is an "open standard" a standard?

Please no "Follow the (assumed) leader, wait for us!", noting the
emphasis on OS/2 as well! And (if reasonably possible) without
causing avoidable damage w.r.t. anything related to other Rexx
interpreters/platforms. So far they did't actually care about us,
in a way it's one-way traffic, sharing stuff isn't a goal on its
own, each RexxUtil.DLL is platform-specific, but the least I can
do is look at whatever they've got. I already did that, and it's
possible for everybody to start talking with e.g. the RexxLA about
a way to go. They can also look at us by the way, and it may not
be a good idea to keep up with every "bad" designed function. We
don't have to. If needed we're on our own without depending on
any author of any Rexx interpreter for any other OS. There's no
need to cause more (avoidable) damage, but OS/2's RexxUtil.DLL
already is aimed at OS/2, just like SysIsFileCompressed() clearly
is aimed at a specific Windows-version (without thinking about a
Sys_Winxx_IsFileCompressed()-function name, that is).



---
0
spamgate
1/9/2008 10:23:20 PM
 >> BTW... who the hell needs SysPi ???

 > it may be more usefull to integrate e.g. RexxMath.DLL into
 > RexxUtil.DLL to get rid of a few good YetAnotherRexxDLLs.
 
Hmz, they've got a RxMath too?! O well, this week I'll be busy
replacing my progress bars with progress circles... ;-)



---
0
spamgate
1/9/2008 11:50:44 PM
 > I'm just advocating that we aim towards a certain level of
 > consistency.
 
And who did disagree with that so far (the aiming may fail, but
that's another issue)? :-o

 > Some functions I'd like to see:
 
Is there any kind of OS/2-related organization (the RexxLA isn't),
which could be used to call the shots, e.g. after you proposed a
change? 

 > - Clipboard access (write/read/clear).
 
One can also think of changing some existing functions, e.g.
SysDumpVariables(<dest>[,<format>]). "<dest>" could perhaps
include the clipboard then. Or a <dest> like EPM (or Notepad,
I don't care), if that's possible/Rexx-enabled.

Please note I'm not mentioning real proposals, I just started this
by identifying RexxUtil.DLL as an independently updatable target,
but it's not my goal to pollute the result by adding SysML.com()'s.

 > If people are determined to go ahead with a replacement
 > (expanded) REXXUTIL, maybe they could go directly in there. 
 > (I've already done some work on some of these functions.)
 
Working on it (so experienced programmers don't have to waist
their valuable time on this :-)), albeit it doesn't have to be
"my" project at all! Maybe we'll need some help later. AFAICT
the first step is to remake RexxUtil.DLL as-is (and perhaps
Rexx.INF), so theoretically (!) it could ship with the OS. When
done, being very carefull with "the" Rexx DLL, we're open for
requests? Preferably shared by an OS/2-community, which may or
may not include e.g. the RexxLA, or "your mother", as members.

 > How do you guarantee that all users will have the new REXXUTIL
 > installed?
 
You cannot. Shipping it with the OS would help, for one. And, of
course, keeping a "the" Rexx DLL instead of many versions would
help too.

 > You're going to end up with a muddled situation where totally
 > different versions of REXXUTIL are floating around

Backward compatible ones, that ain't "totally different".

 > and users aren't necessarily going to know which one they
 > have installed.
 
SysUtilVersion() may help, SysDownloadLatest() too :-), you can
patch most of the existing aps if needed, RxFuncQuery(), and so
on. It also helps that it's "the" DLL, just like you may have to
upgrade your "the" webbrowser once in a while. It requires Warp+,
which in a way is the same issue. Most users will upgrade in time
anyway, just like I install eCS unless the pc cannot handle that.

If you want users of OS/2 2.1 to be able to run your Install.CMD,
I'ld say that's solvable. E.g. by adding an OS version requirement
to the Rexx.INF-documentation, or by testing the version of the
installed RexxUtil.CMD. Then don't call SysFileCopy(), or SAY
"This requires RexxUtil.DLL v2008". 

 > This may be asking for trouble...
 
A major advantages compared to many unused YetAnotherRexxDLLs
is that you'll have to point to a single, well-known, GA, DLL
instead of many unused MyRexx.DLLs.

A valid remark, but I don't think possible progress like this can
be seen as a showstopper forever, and there's no natural moment
to switch to a next version. And perhaps a bigger "problem" is
that the (possibly broken) interpreter itself is unknown, CRexx
or ORexx. That's avoidabe by sticking with CRexx scripting, but
I'ld say updating RexxUtil.DLL (basicly just like a GCC-related
DLL update?) has no such impact, as long as everything keeps
working.



---
0
spamgate
1/9/2008 11:56:20 PM
On Wed, 09 Jan 2008 23:32:53 +0200, ML <spamgate@hotmai1.com> wrote:

> it may be more usefull to integrate e.g. RexxMath.DLL into RexxUtil.DLL to
> get rid of a few good YetAnotherRexxDLLs.

Why? Given that both exist, why do YOU feel the need to bolt all these things
together to form one monolithic library? I just don't see the point.
0
Paul
1/10/2008 12:39:39 AM
On Wed, 9 Jan 2008 15:59:26 UTC, "Rich Walsh" <spamyourself@127.0.0.1> wrote:

> > I just don't want us to jump on our horse and ride off without
> > due consideration for portability.  The more care we put into
> > that beforehand, the less developers will have reason to curse
> > us as they try to migrate their programs from one OS to another.
> 
> This is all perfectly absurd.  Who in their right mind would use
> REXX as a cross-platform scripting language?  On a Top Ten list,
> REXX would come in at #11.
> 
> There are only two constituencies for REXX on the PC:  OS/2 users
> and former mainfamers who now use Windows.  Each group has its own
> parochial concerns that are not, and need not, be relevant to the
> other.  The only meaningful compatibility issue is preserving REXX's
> grammar & syntax so users' basic skill sets remain portable - and
> that's not within the scope of the current discussion.

OK, this is a valid point.  But I think you underestimate the potential
user base for REXX at least somewhat.  For instance, REXX has a user base 
under Linux as well (or else it wouldn't have at least two different 
interpreters available).  In any case, there's good reason to maintain a 
certain level of cross-platform conscience, and it shouldn't cost us much
effort to do so.

 
> RexxUtil is a library of *platform-specific* functions.  It exists
> to serve the needs of OS/2, not Windows or Linux (or MVS for that
> matter). 

True... I'm not suggesting we make the entire library cross-platform.
I'm just advocating that we aim towards a certain level of consistency.
Obviously, some parts of the library will be 100% OS-specific, there's
no denying that.  

 
> Amidst all the verbiage I've waded through, I've yet to see anyone
> propose new functions that would be genuinely useful to OS/2 users.
> At the top of _my_ list would be a wrapper for WinReplaceObjectClass(),
> the lack of which makes REXX unusable for some WPS-related tasks.

Some functions I'd like to see:
 - A way of querying object setup strings (currently WPTOOLS is 
   required for this).
 - Clipboard access (write/read/clear).
 - Getting a list of processes.
 - Query or kill a process by name.
 - A wrapper for DosReplaceModule().
 - Access to the Win32 registry.

For several months, I've been considering proposing a community-based
project to create a "REXXUTIL extensions" library which includes some
of the above, and any other functions that people think are appropriate.
Many of these are available elsewhere, but to get them all you'd need a
multitude of other REXX libraries installed, some of which are old and
no longer maintained, some of which are huge complex libraries with 
dozens of esoteric functions most people will never need, and almost all
of which are closed source.

If people are determined to go ahead with a replacement (expanded) 
REXXUTIL, maybe they could go directly in there.  (I've already done 
some work on some of these functions.)

However, there's one more major problem with expanding REXXUTIL, that I
haven't seen addressed.  How do you guarantee that all users will have 
the new REXXUTIL installed?  Because unless you can guarantee that, how
can you rely on any new functions?

You're going to end up with a muddled situation where totally different
versions of REXXUTIL are floating around, and users aren't necessarily
going to know which one they have installed.  This may be asking for
trouble...

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/10/2008 12:40:01 AM
On 09 Jan 2008 15:59:26 GMT, Rich Walsh <spamyourself@127.0.0.1> wrote:

> This is all perfectly absurd.

Agreed.

> RexxUtil is a library of *platform-specific* functions.

Absolutely. I don't understand the purpose of all the witter about
reimplementing things either.

> At the top of _my_ list would be a wrapper for WinReplaceObjectClass(),
> the lack of which makes REXX unusable for some WPS-related tasks.

Not exactly a difficult task. I implemented it in all my WPS replacement
class DLLs to allow the installation script to do just that.
0
Paul
1/10/2008 12:48:09 AM
 >> it may be more usefull to integrate e.g. RexxMath.DLL into
 >> RexxUtil.DLL to get rid of a few good YetAnotherRexxDLLs.

 > Why?
 
Why not? But because RexxUtil.DLL is "the" Rexx DLL, about anything
outside of that is hardly used.

 > Given that both exist
 
There are far more Rexx DLLs than "both". And we perhaps should stop
counting DLLs. Count (fair) use of 'em instead. You may write a Rexx
DLL covering all basic clipboard operations, and let's assume that's
worth using and has an added value. It's unlikely it's actually going
to be used. First I've to know it exists. If I did knew about it, it
still will hardly get used because it's unlikely "the average user"
has installed it and/or wants to install it and/or knows about it. I
don't think people write great Rexx functions to attract no users,
which basicly always has been the actual situation.

Another example are Rexx DLLs I've written to cover FAQs. I'm not
answering FAQs, but other people may have referred to those DLLs
just once or twice. "Once or twice" doesn't match the F in FAQ, and
I understand why people don't refer to third-party DLLs. Including
usefull functions in "the" Rexx DLL may have prevented the AQ, for
starters. Perhaps I can add an UI to a typical Install.CMD using a
few lines of code. But if you're going to use that, you'ld still
have to write a large Install.CMD to (download and) install my
irrelevant solution. But if you knew RexxUtil.DLL has SysInstall(),
you'ld maybe consider to use that instead of '@COPY "'||file||'"'
target '>NUL's et al. Checking reality learns that MyInstall.DLL
is no match for anything included in "the" Rexx DLL. MyInstall.DLL
would also be a more usefull entry than SysSaveRexxMacroSpace(),
which you've most likely used less frequently than an Install.CMD?
The stuff now included in any RexxUtil.DLL isn't the result of some
kind of a popularity/quality/quantity/usefullness contest.

 > why do YOU feel the need to bolt all these things together
 
That seems like stretching my point and next question the streched
point. For one, did I mention adding "all"? That would be studid,
because then you'll end up with a least 10 versions of SysCls(), and
it certainly isn't about "ME".

Perhaps you should compare it with the whole "C Library Reference",
but without many *.H files not included with the compiler. If there
are more than e.g. 5 highlight functions related to math, including
the already added SysPi(), I suggested to group those in a "MATH.H"
group. That way the documentation may look like small rocks, while
it doesn't matter that much that those rocks are shipped in a large
library. A library of libraries, a bit like a collection of standard
*.H files everybody with the same compiler owns. That wouldn't be
true for Your.DLL. Just like I don't have Your.H installed here, no
matter how usefull Your.H may be.

Besides that, it may encourage to use complete sets instead of some
random collection of functions. We'll have to add SysPi(), because
ooRexxUtil.DLL has it, but does "SAY SysLog10(SysE())" work too? If
not, why not, and isn't a risk that adding loose ends, like SysE(),
would come down to unneeded upgrades/versions? In a way MATH.H now
is actually OS2.H and this semi-MATH.H is perhaps 50% completed. I
don't crunch numbers with Rexx, but I can notice the calculator is
slightly broken/incomplete, and fixing that may pollute the Sys*()-
group with scattered math-related functions. I may not like those
Math*()-functions, but that damage has already been done including
an extra, R(exx)Math.DLL.

Please note about every new function proposed so far is reasonable
and at least worth discussing (and maybe adding). Nobody is going
nuts with the concept (no "YOU", no "all", and so on) and proposed
e.g. adding VisPro* and each version of SysCls(). I also mentioned
a library (of libraries) can get too big, you may start to overlook
e.g. SysInstall() then. but you didn't include that in your "Why?".
I have - intentionally - not added nor seriously mentioned a single
MyFuncWish(), it's not about "ME". A virtual SysInstall() may help
a developer, including helping to incease the number of real users
of such a SysInstall()-function: "COPY"/"UNZIP" works for me, if
YourInstall()-function isn't included in "the" Rexx DLL, and you
can't really rely on me having discovered, downloaded and installed
this Your.DLL.

I've to say there may be another (theoretical) solution to promote
(fair) use of a great YourFunc(). It could be possible to download,
install and RxFuncAdd() missing functions. Then it may not matter
in which file SysSaveRexxMacroSpace() or MyInstall() is, there's no
more "the" Rexx [DLL|documentation] then. I cannot wait until YOU
finished an up-to-date ooRexx.EXE with such a functionality... ;-)



---
0
spamgate
1/12/2008 6:55:46 AM
 > I don't understand the purpose of all the witter about
 > reimplementing things either.
 
A RexxUtil.DLL is OS-specific with many OS-specific functions, but
RexxUtil isn't. Damage has already been done. Has SysFileDelete()
to be removed from RexxUtil.DLL, any OS can delete files without
that and existing code ought to be patched to use "DEL"/"ERASE"
instead? Should R(ex)xMath.DLL be removed from all archives,
because math isn't OS-specific?

 >> At the top of _my_ list would be a wrapper for WinReplaceObjectClass(),
 >> the lack of which makes REXX unusable for some WPS-related tasks.

 > Not exactly a difficult task. I implemented it in all my WPS replacement
 > class DLLs to allow the installation script to do just that.
 
I've to assume he's more than perfectly capable of writing such a
function. Perhaps you could address the real problem here, which
probably is that His.DLL isn't installed on a typical OS/2 pc. The
solution discussed here is to remake/modernize RexxUtil.DLL, and
next allow for such functions to be added to "the" Rexx DLL. That
way it's basicly GA, without requiring e.g. Your.DLLs and My.DLLs;
such a concept failed since Rexx DLL #2 was written, no matter how
usefull a wrapper for WinReplaceObjectClass() may be.



---
0
spamgate
1/12/2008 8:33:46 AM
 >> At the top of _my_ list would be a wrapper for WinReplaceObjectClass(),
 >> the lack of which makes REXX unusable for some WPS-related tasks.

 > Not exactly a difficult task. I implemented it in all my WPS replacement
 > class DLLs to allow the installation script to do just that.

And, as mentioned before too, the above could be solved by adding a
SysAPI("WinReplaceObjectClass",params) to "the" Rexx DLL instead of
adding any of the above to YetAnotherRexx.DLL. That never worked,
and may require both Your.DLL and His.DLL because each (required)
version is no more than just "a" (hardly ever used) My.DLL.



---
0
spamgate
1/12/2008 8:58:54 AM
Rich Walsh wrote:
> On Wed, 9 Jan 2008 10:49:02 UTC, "Alex Taylor" <mail.me@reply.to.address> wrote:
> 
>> Second, there's an (IMO) unfortunate trend (as you point out) 
>> towards cross-platform divergence in REXXUTIL.  Rather than 
>> simply going along with that, I think we all should do what we
>> can to try and encourage a reversal of the trend.  Again, that
>> means telling other platform groups what we're doing, and maybe
>> getting some discussions going about the best way of designing
>> APIs to make them portable.
>>
>> I just don't want us to jump on our horse and ride off without
>> due consideration for portability.  The more care we put into
>> that beforehand, the less developers will have reason to curse
>> us as they try to migrate their programs from one OS to another.
> 
> This is all perfectly absurd.  Who in their right mind would use
> REXX as a cross-platform scripting language?  On a Top Ten list,
> REXX would come in at #11.
> 
> There are only two constituencies for REXX on the PC:  OS/2 users
> and former mainfamers who now use Windows.  Each group has its own
> parochial concerns that are not, and need not, be relevant to the
> other.  The only meaningful compatibility issue is preserving REXX's
> grammar & syntax so users' basic skill sets remain portable - and
> that's not within the scope of the current discussion.
> 
> RexxUtil is a library of *platform-specific* functions.  It exists
> to serve the needs of OS/2, not Windows or Linux (or MVS for that
> matter).  This is how rexx.inf describes it:
> 
>   RexxUtil [...] provides the OS/2 REXX programmer with many versatile
>   functions.  Primarily, these functions deal with the following:
>     OS/2 system commands. 
>     User or text screen input/output (I/O). 
>     OS/2 INI file I/O. 
> 
> Note the emphasis on _O_S_/_2_...
> 
> Amidst all the verbiage I've waded through, I've yet to see anyone
> propose new functions that would be genuinely useful to OS/2 users.
> At the top of _my_ list would be a wrapper for WinReplaceObjectClass(),
> the lack of which makes REXX unusable for some WPS-related tasks.
> 
> BTW... who the hell needs SysPi ???
> 
> 

Rick,

How about this:

/*************************************************************************
* Function:  SysReplaceObject                                            *
*                                                                        *
* Syntax:    call SysReplaceObject orgObject , newObject, flag           *
*                                                                        *
* Params:    orgObject - class being replaced                            *
*            newObject - new class name                                  *
*            flag - TRUE  - Replace the function of orgObject with       *
*                           function of newObject                        *
*                   FALSE - Undo the replacement of orgObject  with      *
*                           newObject                                    *
*                                                                        *
* Return:    0 if fail, 1 if succeed.                                    *
*************************************************************************/

unsigned long SysReplaceObject(unsigned char *name,
                           unsigned long numargs,
                           RXSTRING args[],
                           char *queuename,
                           RXSTRING *retstr)
{
    bool replace;

    if (numargs != 3 || !RXVALIDSTRING(args[0]) ||
            !RXVALIDSTRING(args[1])) return INVALID_ROUTINE;

    if(!stricmp(args[2].strptr,"FALSE") || !stricmp(args[2].strptr,"0")) {
        replace = FALSE;
    } else if(!stricmp(args[2].strptr,"TRUE") ||
!stricmp(args[2].strptr,"1")) {
        replace = TRUE;
    } else return INVALID_ROUTINE;

    RETVAL(WinReplaceObjectClass(args[0].strptr, args[1].strptr,
replace)?1:0)
}
0
Michael
1/12/2008 3:35:15 PM
On Wed, 9 Jan 2008 23:56:20 UTC, spamgate@hotmai1.com (ML) wrote:

>  > Some functions I'd like to see:
>  
> Is there any kind of OS/2-related organization (the RexxLA isn't),
> which could be used to call the shots, e.g. after you proposed a
> change? 

I figure it should be publicized as a NetLabs project.  That way
we can (a) get community support, contribution and feedback, and
(b) publicity.

I really think creating a "RexxUtil Extensions" library is better
than packing many new functions into RexxUtil itself.  That way we
avoid the problems inherent in having multiple versions of RexxUtil
floating around.  And if it's widely publicized as a NetLabs project,
with community involvement, it can hopefully become well-known enough 
to be "the" standard library (after RexxUtil itself).


 
>  > If people are determined to go ahead with a replacement
>  > (expanded) REXXUTIL, maybe they could go directly in there. 
>  > (I've already done some work on some of these functions.)
>  
> Working on it (so experienced programmers don't have to waist
> their valuable time on this :-)), albeit it doesn't have to be
> "my" project at all! Maybe we'll need some help later. AFAICT
> the first step is to remake RexxUtil.DLL as-is (and perhaps
> Rexx.INF), so theoretically (!) it could ship with the OS. When
> done, being very carefull with "the" Rexx DLL, we're open for
> requests? Preferably shared by an OS/2-community, which may or
> may not include e.g. the RexxLA, or "your mother", as members.

I've already written the code to query and kill processes, for
instance.  (I used it in another program, albeit as a command-line
utility rather than a library function.)

 
>  > This may be asking for trouble...
>  
> A major advantages compared to many unused YetAnotherRexxDLLs
> is that you'll have to point to a single, well-known, GA, DLL
> instead of many unused MyRexx.DLLs.

I think this will work if we compromise slightly by having one 
well-known "RexxUtil Extensions" library.  It may even work better, as I
intimated above...

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/13/2008 9:17:02 AM
Alex Taylor wrote:
> On Wed, 9 Jan 2008 23:56:20 UTC, spamgate@hotmai1.com (ML) wrote:
> 
>>  > Some functions I'd like to see:
>>  
>> Is there any kind of OS/2-related organization (the RexxLA isn't),
>> which could be used to call the shots, e.g. after you proposed a
>> change? 
> 
> I figure it should be publicized as a NetLabs project.  That way
> we can (a) get community support, contribution and feedback, and
> (b) publicity.
> 
> I really think creating a "RexxUtil Extensions" library is better
> than packing many new functions into RexxUtil itself.  That way we
> avoid the problems inherent in having multiple versions of RexxUtil
> floating around.  And if it's widely publicized as a NetLabs project,
> with community involvement, it can hopefully become well-known enough 
> to be "the" standard library (after RexxUtil itself).
> 
> 
>  
>>  > If people are determined to go ahead with a replacement
>>  > (expanded) REXXUTIL, maybe they could go directly in there. 
>>  > (I've already done some work on some of these functions.)
>>  
>> Working on it (so experienced programmers don't have to waist
>> their valuable time on this :-)), albeit it doesn't have to be
>> "my" project at all! Maybe we'll need some help later. AFAICT
>> the first step is to remake RexxUtil.DLL as-is (and perhaps
>> Rexx.INF), so theoretically (!) it could ship with the OS. When
>> done, being very carefull with "the" Rexx DLL, we're open for
>> requests? Preferably shared by an OS/2-community, which may or
>> may not include e.g. the RexxLA, or "your mother", as members.
> 
> I've already written the code to query and kill processes, for
> instance.  (I used it in another program, albeit as a command-line
> utility rather than a library function.)
> 
>  
>>  > This may be asking for trouble...
>>  
>> A major advantages compared to many unused YetAnotherRexxDLLs
>> is that you'll have to point to a single, well-known, GA, DLL
>> instead of many unused MyRexx.DLLs.
> 
> I think this will work if we compromise slightly by having one 
> well-known "RexxUtil Extensions" library.  It may even work better, as I
> intimated above...
> 

My source is here http://www.mgreene.org/xfer/newrexxutil.zip. If you 
need a compiled copy just email me at greenemk "at" cox "dot" net.

Everything is in but SysQuerySwitchList which I guess I'll get to soon. 
I am sure there are problems so be careful.

Mike
0
Michael
1/14/2008 1:13:25 AM
On Mon, 14 Jan 2008 01:13:25 UTC, Michael Greene <listsnews@cox.net> wrote:

> > I think this will work if we compromise slightly by having one 
> > well-known "RexxUtil Extensions" library.  It may even work better, as I
> > intimated above...
> 
> My source is here http://www.mgreene.org/xfer/newrexxutil.zip. If you 
> need a compiled copy just email me at greenemk "at" cox "dot" net.
> 
> Everything is in but SysQuerySwitchList which I guess I'll get to soon. 
> I am sure there are problems so be careful.

Don't mistake me, I think it's important to recreate REXXUTIL as open
source as well; if nothing else, it'll be necessary in order to get 
OOREXX fully ported.

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/14/2008 1:29:02 AM
On Sat, 12 Jan 2008 15:35:15 UTC, Michael Greene <listsnews@cox.net> wrote:
> Rich Walsh wrote:

> > At the top of _my_ list would be a wrapper for WinReplaceObjectClass(),
> > the lack of which makes REXX unusable for some WPS-related tasks.
> 
> How about this:
> 
> /*************************************************************************
> * Function:  SysReplaceObject                                            *
> *                                                                        *
> * Syntax:    call SysReplaceObject orgObject , newObject, flag           *
> *                                                                        *
> * Params:    orgObject - class being replaced                            *
> *            newObject - new class name                                  *
> *            flag - TRUE  - Replace the function of orgObject with       *
> *                           function of newObject                        *
> *                   FALSE - Undo the replacement of orgObject  with      *
> *                           newObject                                    *
> *                                                                        *
> * Return:    0 if fail, 1 if succeed.                                    *
> *************************************************************************/

Other than replacing references to 'object' with the word 'class',
perfectly lovely.  Thank you.


-- 
== == almost usable email address:  Rich AT E-vertise.Com == ==
___________________________________________________________________
                |
                |      New!  DragText v3.9 with NLS support
Rich Walsh      |   A Distinctly Different Desktop Enhancement
Ft Myers, FL    |         http://e-vertise.com/dragtext/
___________________________________________________________________

0
Rich
1/14/2008 1:34:07 AM
Alex Taylor wrote:
> On Mon, 14 Jan 2008 01:13:25 UTC, Michael Greene <listsnews@cox.net> wrote:
> 
>>> I think this will work if we compromise slightly by having one 
>>> well-known "RexxUtil Extensions" library.  It may even work better, as I
>>> intimated above...
>> My source is here http://www.mgreene.org/xfer/newrexxutil.zip. If you 
>> need a compiled copy just email me at greenemk "at" cox "dot" net.
>>
>> Everything is in but SysQuerySwitchList which I guess I'll get to soon. 
>> I am sure there are problems so be careful.
> 
> Don't mistake me, I think it's important to recreate REXXUTIL as open
> source as well; if nothing else, it'll be necessary in order to get 
> OOREXX fully ported.
> 

Alex,

The archive is the source to 85 functions and ML (Martin?) is working it 
too.  You have Open Watcom? Download newrexxutil.zip and see how it works.

ML and anyone else interested -

I had a bitch of a time with SysQueryEAList. It works but is not pretty.

Mike


0
Michael
1/14/2008 4:34:05 AM
In <VGyij.5820$M24.1556@newsfe17.lga>, on 01/13/2008
   at 08:13 PM, Michael Greene <listsnews@cox.net> said:

Hi,

>My source is here http://www.mgreene.org/xfer/newrexxutil.zip. If you 
>need a compiled copy just email me at greenemk "at" cox "dot" net.

>Everything is in but SysQuerySwitchList which I guess I'll get to soon. 
>I am sure there are problems so be careful.

I agree with Alex.  I recommend you consider making this a Netlabs
project.  This will give you all the advantages of a TRAC based setup to
manage the project and the project will have much better visibility.

If you do go with Netlabs, I would also recommend planning for a set of
libraries.  It's not that there are not already a number of good libraries
out there, but that most don't have source available.  For example, I find
rxu very useful.  A Netlabs project would provide the opportunities for
those that are interested to contribute new code.

FWIW, I would be willing to assist on an OREXX port for eCS/OS2, but only
if I believed the project has some chance of succeeding.  The last couple
of attempts failed, IMO, mostly because the porters hid out attempting to
get something working before revealing their source code.  Unless you are
really smart, this is a recipe for failure.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
1/15/2008 8:49:03 PM
On Tue, 15 Jan 2008 20:49:03 UTC, Steven Levine <steve53@earthlink.bogus.net> 
wrote:

> I agree with Alex.  I recommend you consider making this a Netlabs
> project.  This will give you all the advantages of a TRAC based setup to
> manage the project and the project will have much better visibility.

Quite...

 
> If you do go with Netlabs, I would also recommend planning for a set of
> libraries.  It's not that there are not already a number of good libraries
> out there, but that most don't have source available.  For example, I find
> rxu very useful.  A Netlabs project would provide the opportunities for
> those that are interested to contribute new code.

Indeed, I think a (smallish) set of libraries is a better approach than
loading everything into an expanded RexxUtil.  IMO it's important to 
strike the right balance between number of libraries (not too many) and
size/orientation of libraries (no "everything and the kitchen sink" 
libraries).  It's tricky to get right, and really needs good advance 
planning.

As I said, RexxUtil should be reimplemented as open source for a number of
sound reasons.  That work seems to be well underway.

Next, we should have an "extended RexxUtil" library, which basically 
contains everything that _should_ have been in RexxUtil, but isn't.  Stuff
like locked-file replacement, clipboard access, better access to setup 
strings, ability to query process/thread information, a kill function, etc.

OTOH, there are relatively specialized areas of support which should 
have their own libraries.  Take my RxLVM library, for instance: it provides
selective (read-only) access to parts of the LVM engine.  These functions 
all go well together with each other, but they're specialized enough that
they don't really have a place in a standard utility library.  The same is
probably true of RxULS.


(Another problem with a lot of the existing libraries is function overlap:
many of them were written before RexxUtil was expanded with things like
SysQuerySwitchList and SysShutdownSystem, and they tend to implement things
that are now available already... oftentimes, different libaries implement
the same redundant functions in slightly incompatible ways.)


> FWIW, I would be willing to assist on an OREXX port for eCS/OS2, but only
> if I believed the project has some chance of succeeding.  The last couple
> of attempts failed, IMO, mostly because the porters hid out attempting to
> get something working before revealing their source code.  Unless you are
> really smart, this is a recipe for failure.

I briefly tried playing with the Linux OOREXX sources using Paul Smedley's
build environment, but I couldn't even get the compile set up right.  I 
never got any farther.

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/16/2008 5:11:07 AM
 > I think a (smallish) set of libraries is a better approach than
 > loading everything into an expanded RexxUtil.

Who mentioned "everything"? If you think I did, please also recall
not going nuts with such a concept. Also please notice a difference 
between looking at everything (why not?) and including everything.

Or, stated otherwise: a library of libraries should look at the 
quality and quantity of any book in the library. Honestly I don't
like all copies of *Cls() included, each maybe representing
a failed attempt to nullify the need for "the" Rexx DLL.

Besides that, don't forget history learns the average, typical Rexx
app is a glorified Install.BAT; not a DBMS.CMD desperately needing 
RxSQL()-support to be available by default.

 > IMO it's important to strike the right balance between number of
 > libraries (not too many)

There are already "too many" Rexx extensions shipped with eCS, so
AFAICT they're hardly used. Yet another YetAnotherRexx.DLL solves  
about nothing, where to draw which line, and you may have noted an
ooRexx RxMath.DLL _and_ math-related functions in RexxUtil.DLL. I
don't know why that ever happened.

 > no "everything and the kitchen sink" libraries)

I cannot recall anybody advocating that, so what's the problem?

But I did address the "too many" indeed, suggesting some kind of a
spreadsheet-like grouping convention. Let's assume basic Clip()-
functions adds 4 functions. I'll settle for eighter SysClip*() or 
Clip*(), slightly preferring SysClip*() here. 

Now math, let's say anything in the lastest ooRexx RexxUtil.DLL. In
a way those functions pollutes the documentation, just like a large
standard *.H file is harder to use than a MATH.H. I'ld put those in 
a Math()-section, as soon as e.g. 6+ functions could be added. In 
*.IPF-lingo:

:h1.Math
:h2.MathCos
:h2.MathE
:h2.MathPi
:h2.MathSin
:h2.MathSqrt
:h2.MathTan
:h1.SysAddRexxMacro
:h1.SysCls
:h1.SysPi
:h1.SysTree

That way anything important (because of already being included in 
RexxUtil.DLL, or because of representing a clear group) is listed
at the :h1.-level, while more specialized functions can be found
using an index at the :h1-level.

 > OTOH, there are relatively specialized areas of support which 
 > should have their own libraries.

Obviously.

BTW, I'm not going to start it, but one may think about some kind
of (unofficial) RexxUtil/2 "committee", employing "workgroups". A
few things could be discusses there, and e.g. the RexxLA can be a
member (!) f such a workgroup discussing e.g. naming conventions,
the cross-platform context, and so on. All you need it about some
website and an e-mailaddress to send proposals to, and it cannot
take a lot of ones time. For one, you may be looking at a release
frequency as often as eCS releases. And you don't have to join any
committee nor workgroup if all you've got is an opinion/proposal.

 > ooRexx

Don't expect the RexxLA to do anything (they may do something!) and
additionally I'ld like to refer to my comments w.r.t. Suri's sf.net-
project. Be clear, get something really going, and so on. Please no
more "Thanks for looking at ooRexx.CPP, you're on your own now!".
Skilled developers are a limited resource, and in the end adding an
easier-to-port Regina/2 to SwitchRx.CMD is an option too, if your
CRexx interpreter would stop working tomorrow, so ooRexx isn't a
must-have. It's nice-to-have, which means a better start should  
help getting in going.



---
0
spamgate
1/19/2008 10:06:08 AM
 > Download newrexxutil.zip and see how it works.

I'll do that, "port" it to VAC++ and I'll test it. No "stress test",
unless that's possible and the source confirms a possible need for a
"stress test".

The thing to compare it with is the original one, based on a 1-on-1
remake. I'll try different environments (CRexx, ORexx, PMRexx) with
some knowledge of any source code, and at least situations like:

     SAY Func()
     SAY Func(arg1,arg2)
     SAY Func(arg1)
     SAY Func(arg1,)
     SAY Func(arg1,'')
     SAY Func(,arg2)
     SAY Func('',arg2)

The "port" to VAC++ isn't a goal on its own. I'm not "the" tester,
so don't wait for me. Your source code isn't listed here, so could
you please post summarizing WhatsNew.TXTs, if needed, as from now,
very briefly showing what's changed for what general reason? E.g.:

     2008-12-31, fix, all functions, replaced all %lf's with %8c's 
     2008-12-28, new, SysCls() now cleans the house too

I'm also not going to really test "broken" situations like a "disk
full"-error condition. I'll be happy with a fprintf() result check 
then, assuming that works if it looks okay to me.

BTW, did you already look at cleaning up on exit, e.g. close()'ing
handles opened? And is your source "stable" now, or are you still 
working on it?



---
0
spamgate
1/19/2008 10:49:38 AM
 > Download newrexxutil.zip and see how it works.

I'll do that, "port" it to VAC++ and I'll test it. No "stress test",
unless that's possible and the source confirms a possible need for a
"stress test".

The thing to compare it with is the original one, based on a 1-on-1
remake. I'll try different environments (CRexx, ORexx, PMRexx) with
some knowledge of any source code, and at least situations like:

     SAY Func()
     SAY Func(arg1,arg2)
     SAY Func(arg1)
     SAY Func(arg1,)
     SAY Func(arg1,'')
     SAY Func(,arg2)
     SAY Func('',arg2)

The "port" to VAC++ isn't a goal on its own. I'm not "the" tester,
so don't wait for me. Your source code isn't listed here, so could
you please post summarizing WhatsNew.TXTs, if needed, as from now,
very briefly showing what's changed for what general reason? E.g.:

     2008-12-31, fix, all functions, replaced all %lf's with %8c's 
     2008-12-28, new, SysCls() now cleans the house too

I'm also not going to really test "broken" situations like a "disk
full"-error condition. I'll be happy with a fprintf() result check 
then, assuming that works if it looks okay to me.

BTW, did you already look at cleaning up on exit, e.g. close()'ing
handles opened? And is your source "stable" now, or are you still 
working on it?



---
0
spamgate
1/19/2008 10:49:39 AM
Alex Taylor wrote:
> On Tue, 15 Jan 2008 20:49:03 UTC, Steven Levine <steve53@earthlink.bogus.net> 
> wrote:
> 
>> I agree with Alex.  I recommend you consider making this a Netlabs
>> project.  This will give you all the advantages of a TRAC based setup to
>> manage the project and the project will have much better visibility.
> 
> Quite...

Sounds like a great idea, but I have to learn svn.

>> If you do go with Netlabs, I would also recommend planning for a set of
>> libraries.  It's not that there are not already a number of good libraries
>> out there, but that most don't have source available.  For example, I find
>> rxu very useful.  A Netlabs project would provide the opportunities for
>> those that are interested to contribute new code.
> 
> Indeed, I think a (smallish) set of libraries is a better approach than
> loading everything into an expanded RexxUtil.  IMO it's important to 
> strike the right balance between number of libraries (not too many) and
> size/orientation of libraries (no "everything and the kitchen sink" 
> libraries).  It's tricky to get right, and really needs good advance 
> planning.

Yet another good idea.

> As I said, RexxUtil should be reimplemented as open source for a number of
> sound reasons.  That work seems to be well underway.
> 
> Next, we should have an "extended RexxUtil" library, which basically 
> contains everything that _should_ have been in RexxUtil, but isn't.  Stuff
> like locked-file replacement, clipboard access, better access to setup 
> strings, ability to query process/thread information, a kill function, etc.

Check this:

http://www.mgreene.org/xfer/newrexxutil.zip

I just updated it 19 Jan. A lot of clean up, SysSearchPath works 100%, 
and, with some tips, a version of oorexx SysFileTree is working.  The 
included demo script passes and ecsmt (which pointed me to some errors) 
now works with it.

I also threw in all the oorexx math functions because it took very 
little effort to add.

It seems safe enough now that I run it as the system rexxutil.dll.

> OTOH, there are relatively specialized areas of support which should 
> have their own libraries.  Take my RxLVM library, for instance: it provides
> selective (read-only) access to parts of the LVM engine.  These functions 
> all go well together with each other, but they're specialized enough that
> they don't really have a place in a standard utility library.  The same is
> probably true of RxULS.
> 
> 
> (Another problem with a lot of the existing libraries is function overlap:
> many of them were written before RexxUtil was expanded with things like
> SysQuerySwitchList and SysShutdownSystem, and they tend to implement things
> that are now available already... oftentimes, different libaries implement
> the same redundant functions in slightly incompatible ways.)
> 
> 
>> FWIW, I would be willing to assist on an OREXX port for eCS/OS2, but only
>> if I believed the project has some chance of succeeding.  The last couple
>> of attempts failed, IMO, mostly because the porters hid out attempting to
>> get something working before revealing their source code.  Unless you are
>> really smart, this is a recipe for failure.
> 
> I briefly tried playing with the Linux OOREXX sources using Paul Smedley's
> build environment, but I couldn't even get the compile set up right.  I 
> never got any farther.
> 

Could OW C++ be used or is it not yet up to the task?

Mike
0
Michael
1/19/2008 7:36:47 PM
In <jjskj.33446$Ft5.4939@newsfe15.lga>, on 01/19/2008
   at 02:36 PM, Michael Greene <listsnews@cox.net> said:

Hi,

>>> I agree with Alex.  I recommend you consider making this a Netlabs
>>> project.  This will give you all the advantages of a TRAC based setup to
>>> manage the project and the project will have much better visibility.
>> 
>> Quite...

>Sounds like a great idea, but I have to learn svn.

Subversion is pretty easy.  The basics of what you need to know are at

  http://svn.netlabs.org/fm2#Gettingthesources

If you  have commit access to the repository <g>, you need to know one
more command

  svn commit

Subversion can do a lot of complex things, but you can learn them as you
need them.

>> I briefly tried playing with the Linux OOREXX sources using Paul Smedley's
>> build environment, but I couldn't even get the compile set up right.  I 
>> never got any farther.

>Could OW C++ be used or is it not yet up to the task?

Hard to say without testing.

Of course, without knowing what "couldn't even get the compile set up
right" means, one can't know how much effort fixing this will take.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
1/19/2008 11:59:32 PM
 > IBM flat cold refused to give REXXLA the OS/2 REXX code.
 
That isn't what the RexxLA mentions about it, while it's possible
to do so diplomaticly. But it's extremely likely that it happened
as you describe it. Then the only "blame" (note the "'s) is that
they didn't refuse the Windows version (they were after) in those
negotiations. One of their paper goals is the furthering of Rexx,
and this left the perhaps biggest pc-based installed base and user
base behind. Again, please note the "'s. All of this is slightly
off-topic, but flat cold refusing even the Windows version could
have resulted in including the Windows IDE. A few questions can
be asked here, albeit the matching answers may show it's the best
result possible, but OTOH some remark was made earlier about being
after the Windows version. If that's basicly true, I think IBM did
experience a smooth negotiation process with every demand happily
honoured, and the RexxLA got what they assumed to be important
for themselves (being mainly IBM Object Rexx for Windows-users).
They wanted a (/this) Rexx interpreter for Windows, according to
the remarks made about this topic, and they have (just) that. 
 


---
0
spamgate
1/20/2008 12:48:36 AM
Be careful with that last version - using ecsmt with it chops LIBPATH 
and so on to 256 lengths - I'm fixing now

Mike
0
Michael
1/20/2008 1:12:13 AM
On Sat, 19 Jan 2008 10:06:08 UTC, spamgate@hotmai1.com (ML) wrote:

>  > IMO it's important to strike the right balance between number of
>  > libraries (not too many)
> 
> There are already "too many" Rexx extensions shipped with eCS, so
> AFAICT they're hardly used. Yet another YetAnotherRexx.DLL solves  
> about nothing, where to draw which line, and you may have noted an
> ooRexx RxMath.DLL _and_ math-related functions in RexxUtil.DLL. I
> don't know why that ever happened.

Too many?  AFAIK, only ECSRXLIB and REXXINI actually ship with it and
are installed in the LIBPATH.


>  > no "everything and the kitchen sink" libraries)
> 
> I cannot recall anybody advocating that, so what's the problem?

Nobody did.  I was just defining the two extremes in order to triangulate my 
own proposal.

 

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/20/2008 1:13:01 AM
On Sat, 19 Jan 2008 19:36:47 UTC, Michael Greene <listsnews@cox.net> wrote:

> > As I said, RexxUtil should be reimplemented as open source for a number 
> > of sound reasons.  That work seems to be well underway.
> > 
> > Next, we should have an "extended RexxUtil" library, which basically 
> > contains everything that _should_ have been in RexxUtil, but isn't.  
> 
> http://www.mgreene.org/xfer/newrexxutil.zip
> 
> It seems safe enough now that I run it as the system rexxutil.dll.

I realize I was unclear.  By "an extended RexxUtil library" I meant a NEW
library (not part of RexxUtil), e.g. "RXEXUTIL" which contains these new
functions.  I still think it's a bad idea to put new functions into 
RxxxUtil itself.


> > I briefly tried playing with the Linux OOREXX sources using Paul 
> > Smedley's build environment, but I couldn't even get the compile set up 
> > right.  I never got any farther.
> 
> Could OW C++ be used or is it not yet up to the task?

No idea, but it's not likely to compile the Linux source code right away.

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/20/2008 1:15:02 AM
 >> It's possible that a VIO app morphes into a PM app, and another
 >> component may stop working because VIO is required.

 > As I said, with current kernel I know no situation when "VIO is
 > required".
 
Excuse me, a more accurate problem here is VIO full-screen printf()
or a windowed VIO WinMessageBox().



---
0
spamgate
1/20/2008 1:17:06 AM
On Sat, 19 Jan 2008 23:59:32 UTC, Steven Levine <steve53@earthlink.bogus.net> 
wrote:

> >Sounds like a great idea, but I have to learn svn.
> 
> Subversion is pretty easy.  The basics of what you need to know are at
> 
>   http://svn.netlabs.org/fm2#Gettingthesources

I think it's a fair bit easier to use than cvs.  

Also, you can use a GUI like SmartSVN which can shield you from the command-
line syntax.

 
> >> I briefly tried playing with the Linux OOREXX sources using Paul 
> >> Smedley's build environment, but I couldn't even get the compile set up 
> > right.  I never got any farther.
> 
> Of course, without knowing what "couldn't even get the compile set up
> right" means, one can't know how much effort fixing this will take.

I don't even remember what the problem was.  I suspect it was a failure to
find all the required #includes or something like that.  Anyway, I don't 
have the time or inclination to worry about it now.

-- 
Alex Taylor
Fukushima, Japan
http://www.cs-club.org/~alex

Please take off hat when replying.
0
Alex
1/20/2008 1:18:02 AM
In <mdq090pMZSKk-pn2-Guc95MCHnHrO@localhost>, on 01/19/2008
   at 07:18 PM, "Alex Taylor" <mail.me@reply.to.address> said:

Hi,

>I think it's a fair bit easier to use than cvs.

I find them pretty much the same, but I've got a bit of cvs experience.

I still tend to use cvs for smaller projects that are unlikely to branch
and for private projects with a local repository.  For these, cvs performs
a bit better and has a much smaller disk space footprint.  This eases the
resources required to back up the repositories and the workspaces.

What I would like is an option for subversion where if for local
repositories the shadow copies of the current version would be suppressed. 
This would make the overall disk comparable to cvs with no loss of
functionality.

>Also, you can use a GUI like SmartSVN which can shield you from the
>command-
>line syntax.

SmartSVN can definitely help new users get started.  I use a combination
of 4OS2 aliases and editor macros that are optimized for the way I work.

>I suspect it was a failure
>to find all the required #includes or something like that.

Makes sense.  It was probably looking for linux specific includes because
it thought it should

>Anyway, I
>don't  have the time or inclination to worry about it now.

Agreed.  I'm willing to assist, but I don't have suffient interest to do
the port myself.

Steven

-- 
--------------------------------------------------------------------------------------------
Steven Levine <steve53@earthlink.bogus.net>  MR2/ICE 3.00 beta 10pre #10183
eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
--------------------------------------------------------------------------------------------

0
Steven
1/20/2008 2:31:22 AM
[A complimentary Cc of this posting was sent to
ML
<spamgate@hotmai1.com>], who wrote in article <SEqkHlQNAJqa090yn@hotmai1.com>:
> 
>  >> It's possible that a VIO app morphes into a PM app, and another
>  >> component may stop working because VIO is required.
> 
>  > As I said, with current kernel I know no situation when "VIO is
>  > required".
>  
> Excuse me, a more accurate problem here is VIO full-screen printf()
> or a windowed VIO WinMessageBox().

I have no idea what you are talking about.  printf() is not an OS
call; WinMessageBox() works fine from a morphed-to-PM application.

Puzzled,
Ilya
0
Ilya
1/20/2008 7:53:55 AM
 >> Excuse me, a more accurate problem here is VIO full-screen printf()
 >> or a windowed VIO WinMessageBox().

 > WinMessageBox() works fine from a morphed-to-PM application.

And how does a WinMessageBox() look when called from a morphed-
to-PM-for-some-unrelated-reason full-screen application? A real
example may be the way the OS informs you about a printer problem
while printing. From a full-screen session you'll have to go to the
PM yourself, according to a VioPopUp()-message, instead of the OS
smashing the PM in your face. The latter may work technically, but
the choice made is to not smash the PM in your face. Another app
could use/prefer the same way to communicate with the user using
e.g. printf() when FS, or a smoother WinMessageBox() when not FS.



---
0
spamgate
1/20/2008 10:34:44 AM
[A complimentary Cc of this posting was sent to
ML
<spamgate@hotmai1.com>], who wrote in article <EPykHlQNAdOS090yn@hotmai1.com>:
> could use/prefer the same way to communicate with the user using
> e.g. printf() when FS, or a smoother WinMessageBox() when not FS.

I see.  You just stick your remark into a part of the thread which
discusses A VERY SPECIFIC question: when morphing-back-to-VIO is
needed.  AFAICS, your remark is absolutely irrelevant to this
discussion (and is, anyway, beaten to death in other places of this
thread; e.g., EMX does this for its panic() messages).

Yours,
Ilya
0
Ilya
1/20/2008 4:54:17 PM
Reply:

Similar Artilces:

Accessing a dll from within Access
Hi, My company has a database which I need to read from my database now and again. This db can only be read via a dll written in C#. I need to read data from this database and popule a table in my own database which is programmed via MsAccess. How would I go about communicating to the dll via VBA, Thanks, Barry. On Mon, 10 Dec 2007 02:27:56 -0800 (PST), bg_ie@yahoo.com wrote: That depends because there are 3 styles of DLLs. If it's a .Net DLL you can't call it. If it's a .Net component with a COM wrapper around it, it's like any other COM DLL and you can set a reference ...

Programmers, Programmers, Programmers, ...
As Steve Balmer correctly stated, while making his monkey dance, it is applications and hence programmers that make a platform. The fact though is that if you want to do professional programming, then Linux is the platform for you. I know that this statement will get the heckels up on a lot of trolls in C.O.L.A, but I have a recent experience that proves this. I am currently working for a Windows only house producing a system that receives and transmits around 1000 telegrams per second in each direction on a UDP socket, translates them into a different format and creates a log entry for each ...

Dynamically load a dll and us it (in a rexx dll)
Hi, I've written a dll that can be used with ODBC connections and rexx to overcome the current limitations of rexxsql and gui apps in OS/2. The code work ass I've compiled it for another system, but I'm having problems adding the equivalent features to the OS/2-eCS version. Is it possible to load ODBC32.dll dynamically in a rexx dll and if so, how? The OpenWatcom Debugger barf on DosLoadModule and says "access violation". init of class rx2ODBC: rx2ODBC() : isInf( false ), isMsg( false ), isErr( false ) { #ifdef __OS2__ dll =...

os.access(file, os.R_OK) on UNIX and WINDOWS
Hello, on UNIX I changed the permission of a file "myfile" with chmod 000 myfile. Then I got 0 from os.access(myfile, os.R_OK). This is ok. Then I checked the same file on WINDOWS (with samba): I got "True" from os.access(myfile, os.R_OK). I think it is not ok?! In my python script I check the return value of os.access(myfile, os.R_OK) and when it is "True" I copy the file with shutil.copy(myfile, newfile). But on WINDOWS I get the error: IOError: [Errno 13] Permission denied. How can I check the right file access with python on WINDOWS before copying the file...

Accessing OS 9 Shared Printer from OS 10.2
Hi Everyone... I have a shared Epson USB printer connected to an iMac running OS 9. I shared it through the "USB Printer Sharing" control panel. I am trying to find a way to access it from on OS 10.2.8 iBook. I can't seem to figure out how to install it in the Printer Dialog. Any ideas would be great! Much thanks in advance! Jameson <jameson_ray@comcast.net> wrote: > I have a shared Epson USB printer connected to an iMac running OS 9. I > shared it through the "USB Printer Sharing" control panel. I am trying > to find a way to access it from on OS 10.2...

PM windows from REXX helper DLL and other REXX/C questions
I'm trying to write a REXX utility DLL which needs to open the system file dialog (well in fact my own extended version). I have not yet figured out how this can be realized. There must be a way, the question is how. I couldn't even get a message box to be shown. The relevant C function so far opens PM, creates a message queue and starts a thread for the dispatching of messages. It creates an object window as owner window for the dialog. Parent for the dialog is HWND_DESKTOP. This all seems to be too complicated. I haven't found any documentation about how to use PM...

Accessing Access
Hello, what would be a good module for accessing data contained in a MS Access database file? Are there any examples of doing this that you know of? In article <nn1Ah.2617$2%1.2205@trndny02>, <QoS@domain.invalid.com> wrote: > >Hello, what would be a good module for accessing data contained in >a MS Access database file? Are there any examples of doing this >that you know of? Depends what kind of platform you can use. If you are under Windows, DBD::ODBC will work wonders. If you `bridge' Windows <-> Unix, you can set up a DBI::ProxyServer on a windows...

RE: os.access(file, os.R_OK) on UNIX and WINDOWS
[kai=20rosenthal] |=20on=20UNIX=20I=20changed=20the=20permission=20of=20a=20file=20"myfile"=20= with=20chmod=20000 |=20myfile.=20Then=20I=20got=200=20from=20os.access(myfile,=20os.R_OK).=20= This=20is=20ok. |=20 |=20Then=20I=20checked=20the=20same=20file=20on=20WINDOWS=20(with=20samba)= : |=20I=20got=20"True"=20from=20os.access(myfile,=20os.R_OK).=20I=20think=20= it=20is=20not=20ok?! Ummm.=20This=20is=20a=20touch=20similar=20to=20a=20parallel=20thread=20abo= ut os.X_OK=20on=20Win32.=20At=20the=20risk=20of=20being=20grilled=20by=20bett= er-informed types,=20the=20fact=20is...

Accessing access
Can anyone help me please? This has been driving me nuts for ages. I want to use vb 6.0 to control data in a database (an access database). I've looked at tutorial all over the net but I don't want to use a data grid or anything like that because I want to control the database, not see it. So far, from one tutorial I've managed to get something on the lines of this ****************************************** dim db as Database Set db = OpenDatabase("E:\BT.mdb") dim rspeople as recordset set rspeople = db.openrecordset("people") **************...

access to Access
I've been reading some old posts that talk of an inability to connect to an Access database with RB. Is that (still) true? If so, that would be a show stipper for us. Thanks for any insight, dave In article <1187719558.603002.257260@q3g2000prf.googlegroups.com>, Dave <davegp2@msn.com> wrote: > I've been reading some old posts that talk of an inability to connect > to an Access database with RB. Is that (still) true? If so, that > would be a show stipper for us. I've never tried it, but I think you should be able to access Access via ...

Accessing dll
I am a complete novice to Python. I wish to access a dll that has been written to be compatible with C and VB6. I have been told that after running Python I should enter "from ctypes import *" which allows Python to recognize the dll structure. I have placed the dll into my active directory (if that's the correct word, one on my path) for simplification. I tried: "import name.dll" but this just gave me an error telling me that there was no such module. Can someone please help? Richard Am 06.09.2012 17:07, schrieb Helpful person: > I am a compl...

access to Access
We use MS access 2000 at work and few people know how to work it including me. We are using it on a network and more than one person is trying to access it at once. Needless to say this isn't working as one has to log out first before another can enter data. Is there an easy way around this? Or a complicated way, actually I'll take anyway. Thanks Mike We have just started this database so any changes would be better done sooner. Mike Kelliher wrote: > We use MS access 2000 at work and few people know how to work it > including me. > We are using it on a network and mo...

Implementation of REXX's PARSE as DLL or COM DLL?
G'day everyone I'd like to use REXX's PARSE functionality in my own project but it's not written in REXX. Is there any way of getting access to the PARSE functionality via a DLL or COM DLL? Kind regards, Bruce. axtens wrote: > G'day everyone > > I'd like to use REXX's PARSE functionality in my own project but it's > not written in REXX. Is there any way of getting access to the PARSE > functionality via a DLL or COM DLL? > > Kind regards, > Bruce. That would be neat. -- Gary Scott mailto:garylscott@sbcglobal dot net Fortran Libr...

Clipboard access?
Can anybody give me the name of a WinAPI function--any function--to handle the clipboard? I'll look it up on MSDN. Thank you! Harry, > Can anybody give me the name of a WinAPI function > --any function--to handle the clipboard? You really are ACTIVILY REFUSING to try yourself first, are you ? :-(( Guess what I got when I plugged "Winapi clipboard" into Google .... With noth-that-much regards, Rudy Wieser -- Origional message: Harry Potter <rose.joseph12@yahoo.com> schreef in berichtnieuws 338066af-c43f-42d0-abba-786849e35d6c@googlegroups.com.....

Web resources about - Accessing clipboard from REXX DLL - comp.os.os2.programmer.misc

Highest Percentage Of Opera Mini Users Accessing Facebook? Macau
If you were asked to guess which country had the highest percentage of users of Opera mobile Web browser Opera Mini users accessing Facebook ...

International Users Accessing Facebook Places Through US VPN Accounts
By using a virtual private network (VPN) hosted in the United States, Facebook users from around the world are accessing Facebook Places. The ...

What are some alternatives to Yodlee for accessing bank information?
Clay Loveless , Founder, Jexy. Co-founder, Mashery. Founder, Jexy. Co-founder, Mashery.

Cloud Console - Accessing files in cloud storage for iPad on the iTunes App Store
Get Cloud Console - Accessing files in cloud storage on the App Store. See screenshots and ratings, and read customer reviews.

Meryl Streep On Accessing The Characters Within - YouTube
Meryl Streep talks about the importance of an actors work representing their ability. CONNECT WITH AFI: http://facebook.com/AmericanFilmInstitute ...

Student pleads guilty to accessing records about Frances Abbott design scholarship
The Sydney student who leaked information about a fashion school scholarship controversially awarded to the daughter of the Prime Minister has ...

Accessing a headline opinion
Accessing a headline opinion

Sharp increase in authorities accessing private data
Australian law enforcement and government agencies have sharply increased their access without warrant to vast quantities of private telephone ...

Former librarian charged with accessing student records of Frances Abbott
A former part-time librarian at a Sydney design school has been charged after she allegedly accessed student records of Prime Minister Tony Abbott's ...

Frances Abbott scholarship: Sydney woman pleads guilty to accessing Whitehouse Institute records on PM's ...
A Sydney woman who leaked the student records of Tony Abbott's daughter pleads guilty. A Sydney woman who leaked the student records of Prime ...

Resources last updated: 1/30/2016 10:10:28 PM