As to your question, it's a good idea to detach your GUI logic from your business logic, so I think you should remove all direct DB-GUI connection ASAP.
That's actually part of what I'm trying to accomplish. I want to create routines for C.R.U.D. (on a table-by-table basis) that will reside in UDFs inside (interfaceless) persistent procedures.
While I guess I'm not fully decoupled since I am talking about having the actual record buffer available inside my screen, I am at least encapsulating my business logic and keeping "minimal" stuff in the UI. Do you think this much (coupling) is also trouble? I guess I was trying to take advantage a bit of Progress' default behavior. Maybe I shouldn't try to have it both ways.
One way to do this which also offers a solution to your question is to use a temp table (defined like your DB table) and update that on your screen, then BUFFER-COPY it to the DB table it represents when complete. You can pass temp-table records in parameters too.
I thought about using a temp-table, but say I allow the user to update a field that is part of a unique index on the screen. In order to pass a temp-table
that has been modified on-screen (as a table or as a buffer parameter) to my UDF, I'd have to first allow
assign to happen (so the changes are reflected in the parameter). Say the user changed a unique index field to a value that already exists in the database - Progress' default error message is going to pop-up on assign of the temp-table (before I get a chance to validate it myself inside my UDF). This is the same exact problem I run in to if I was using the actual record buffer (vs. a temp-table) and allow
assign to happen.
Also (though a little too much effort to solve this one issue), ADM2 smart objects provide a framework which provides easy (once you've got to know it) methods for developing traditional maintenance screens.
I've been out of GUI for years. Last time I read anything about ADM the reviews were kind of negative. I definitely need to re-evaluate this when it's time to rewrite our app. but yeah you're right at this very moment in time this probably isn't practical.
Section 9.5 "Data-handling Statements" in the Programming Handbook talks to the different buffers (screen, record & database). I guess ideally I wish there was a way to have access to the screen buffer the same way we have access to the record buffer.
my_udf(buffer customer) is exactly what I want to do except that it's using the record buffer (which won't reflect changes the user might have made on-screen).