OK Marcia, I've read it. It explains some of the behaviour but by no means all... here's one thats getting right up my nose as we speak!

if not used('USERFILE')
use Progpath+'USERFILE' in 0 exclusive
endif
select USERFILE

USERFILE is being used by a form in a PDS. From that form we call another form with its own PDS. On exiting that second form we need to access USERFILE and that bit of code is supposed to do it.

However, it gets to the second line and halts with 'File is in Use'

If I 'ignore' that, it then fails to 'select' USERFILE because it doesn't exist! In other words in the space of four lines its contradicted itself twice!

Now, I can understand, barely, that it passed the test 'if not used...' because it was being used in a PDS only.

I can also understand that an attempt to use it exclusively would then fail because the Private Data Session still has a handle on the file - so its not available to be used exclusively.

What I can't understand is how else you're supposed to test for the availability of the file without resorting to low level kludges like FOPEN, FCLOSE etc which aren't exactly elegant OOP!

As it happens, I also figured out, because the PDS, I didn't need that bit of code anyway, so it didn't present any problems, but it still leaves that questionmark hanging in the air.

The other issue that I can't wrap my head round is the disappearing form name!

Outside the form I can refer to methods within the form using the syntax "FORMNAME.METHOD."

Unless, that is, the form is running a PDS. Then the form's name becomes invisible outside the form and I have to use "_SCREEN.ACTIVEFORM.METHOD" which works well enough. But why should this be necessary. I understand the benefits of keeping the data itself private in a PDS but I can't see the point of hiding useful details like the name of the form currently being run!

To me these look like glaring inconsistencies or at least weak design. But I'm conscious that it may just be that I don't yet see the big picture.

What am I missing?

Harry