screen buffer access

[smapdi636]

Hi all. 9.1E 04, Win32 GUI.

Is there any way to pass the screen buffer of a record as an input parameter to a UDF? Similar to my_udf(buffer customer) but using the screen rather than record buffer?

I'm really trying to avoid passing individual fields i.e. my_udf(customer.name:screen-value, customer.number:screen-value, ...). Not only do I not want to write/maintain all those parameters, I also do not want to "convert" non-character data-types (because I'd be using the :screen-value attribute).

Also I cannot assign the screen buffer to the record buffer prior to running my UDF because I don't want unique index validation to fire.

 

[mpowell_esq]

For GUI that is simple, just access the widgets attribute. eg.
WidgetName:SCREEN-VALUE.
Though to manipulate, when accessing the data you require the frame that the data is in.This is applicable for v8 Plus GUI Progress versions.
Use this syntax.
DO WITH FRAME {&FRAME-NAME}:
var = WidgetName:SCREEN-VALUE.
END.
Further example;
DO WITH FRAME {&FRAME-NAME}:
var = table.field:SCREEN-VALUE.
END.

 

[smapdi636]

For GUI that is simple, just access the widgets attribute. eg.
WidgetName:SCREEN-VALUE.
Though to manipulate, when accessing the data you require the frame that the data is in.This is applicable for v8 Plus GUI Progress versions.
Use this syntax.
DO WITH FRAME {&FRAME-NAME}:
var = WidgetName:SCREEN-VALUE.
END.
Further example;
DO WITH FRAME {&FRAME-NAME}:
var = table.field:SCREEN-VALUE.
END.

Thanks but I'm wondering if you only read the subject of my post but not the post itself.

If that is the case I probably should have titled the post "Is there any way to pass the screen buffer of an entire record as an input parameter to a user-defined function?"

 

[mpowell_esq]

Re: Do the Math

Maybe if you read the post you will be able to follow the title.
I have given detail of how to access the actual data, simply manipulate it as required.
DO WITH FRAME {&FRAME-NAME}:
cLocalVar = WidgetName:SCREEN-VALUE. /* you have accessed the required data */
END.

Now manipulate it as required.
e.g RunUDF INPUT (cLocalVar)

Though a more appropriate value to pass would be the db row nbr. Then in the UDF you are able to access all the required data of that row (the different field values) at will.
I hope the identified method will enable you to do the math as appropriate for your shop data. You are the 1 whom is being paid to be an advanced business application architect, do some math.

 

[smapdi636]

Whoa, easy chief. I didn't mean to offend and no reason to get nasty.

I have given detail of how to access the actual data, simply manipulate it as required.
DO WITH FRAME {&FRAME-NAME}:
cLocalVar = WidgetName:SCREEN-VALUE. /* you have accessed the required data */
END.

I had specified in my post, "I'm really trying to avoid passing individual fields i.e. my_udf(customer.name:screen-value, customer.number:screen-value, ...)".

I want an entire record's buffer, not individual fields, also as I stated in my post, "Similar to my_udf(buffer customer)".

Though a more appropriate value to pass would be the db row nbr. Then in the UDF you are able to access all the required data of that row (the different field values) at will.

Also as I said, "Also I cannot assign the screen buffer to the record buffer prior to running my UDF because I don't want unique index validation to fire".

 

[mpowell_esq]

You CAN NOT avoid passing fields. You require 1 field ALWAYS. The row nbr, having this field will the realize access to the other fields (columns for M$ users). You require the handle to the row so you can realize when required other values of that row. The row nbr, is the primary unique field for identification purposes. Eg, product nbr / item nbr, depending on the use or something like the sales nbr / customer nbr. The primary unique value to get to the row for all the other values. Once you have the row nbr you can access the db from a different place still realizing the required data.
Can you do the math now??

 

[smapdi636]

I'm not sure why you continue to be insulting.

However as I said, I'm looking to get at the screen buffer, not the record nor database buffer.

So passing a primary key ("row nbr"), as far as I can tell, isn't going to help me as that'd only allow me to read the database buffer.

 

[KnutHandsome]

I'm not sure why you continue to be insulting.

He's always like that, it's part of his 'appeal'.

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.

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.

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.

 

[smapdi636]

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).

 

[smapdi636]

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.

The more I think about this - you're absolutely right. I should NOT be trying to pass a buffer as it requires UI/DB coupling. I couldn't (elegantly) reuse this code in WebSpeed (for example) because there is no screen-buffer in WebSpeed.

I was originally trying to avoid the tedium & maintenance involved with individual input parameters for each field of a table. Say I have these UDF calls all over the system, then I add a field to my table. Now I have to change all those calls... Maybe a code-generator combined with include files could alleviate some of the code-duplication involved with that approach. Or maybe there is just no way around it.

Anyway, thank-you. I've been struggling with this for a few days now. I think this gives me pretty concrete reasoning that I need to solve this in another way.

 

[KnutHandsome]

[crosspost]

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.

Well, you can:

1: remove the unique constraint on the index for the temp table (or temporarily assign unknowns to unique keys) or
2: test the screen-values individually first wherever a group assign would produce an error or
3: use assign no-error, and test the error-status afterwards or
4: force the user to use a lookup for the unique components - it's hardly fair to expect them to remember them all.

The normal approach to user input screens (or the one I use when not using ADM2, rare these days, so may be a little rusty) is method 2, ie. allow the user to enter whatever they want in any fields, then test them all when the Submit button is pressed, displaying any errors as appropriate, combined with method 4 for the fields where the user "can't be trusted".

 

[mpowell_esq]

Syntax , can you work and apply??

DO WITH FRAME {&FRAME-NAME}:
ThisIsTheAttribYouWishToAccessVar = WidgetName:SCREEN-VALUE .
END.

Here you are, is this what you require? Are you able now to blagg this and apply. Remember you ARE a highly paid Advanced Business Software Architect, not a noddy computer analyst.

 

[KnutHandsome]

Last time I read anything about ADM the reviews were kind of negative.

I nearly turned down my current job because ADM2 was used here, and I had heard the same stuff (but be aware that ADM2 is a different framework to ADM1).

Truth is, it's great for normal business applications, ie. simple maintenance screens, but not so hot if you need to do anything complicated UI wise, when it can become a little unwieldy, but then again Progress is not great for beyond-basics UI manipulation, and you are not forced to use SmartObjects all the time - you can mix and match Smart and non-Smart windows in the same appllication, so I really don't see the problem with it - it's just an extra tool that is very useful times.

The 3 major problems with it are:

1. Lousy documentation - you will struggle to learn it without a mentor.
2. Ugly (sometimes) code-behind.
3. People who dismiss it, and give its bad rep, normally have no experience with it (like me before I used it), or are trying to use it as a cure-all, rather than seeing it as a great way to create simple business windows quickly.

 

[smapdi636]

mpowell_esq ... Lol. You're a trip man...

Here you are, is this what you require?

No, as I've tried to communicate to you several times now. Thanks anyway.

 

[KnutHandsome]

Are you able now to blagg this and apply. Remember you ARE a highly paid Advanced Business Software Architect, not a noddy computer analyst.

This forum would be boring without you, dude.

Personally, I am not highly paid, and although I use the former title whenever possible, my boss describes me as the latter, with added swear words .

 

[smapdi636]

...seeing it as a great way to create simple business windows quickly

I really like the idea of this. I recently spent some time with Ruby On Rails.

It sounds like the ADM is somewhat similar to the RoR scaffolding in that the scaffolding gives you a really easy way to build simple maintenance screens (if interested, see "Creating a weblog in 15 minutes" presentation on the RoR site).

One thing that was nice about RoR, as your screens got more complex, the scaffolding kind of fell away and allowed you to build in as much complexity as needed.

 

[mpowell_esq]

KnutHandsome R U Knutts??

Why did you turn down a position because it used ADM 2? The ADM is like totally amazing. When PSC brought in ADM for V8 GUI with ADM(1) is was a FANTASTIC solution / method. Admittedly it fell-down which is why we know have ADM 2. Which in itself soo rules. Yes it is restricting, though that is a benefit. If you follow the ADM route, you KNOW where the bugs will be and where your code falls down. What SERIOUS business issues are you unable to execute using the ADM route?? The ADM is simply a mecanism/ methodology to enable businesses to deliver a structured solution. The ADM reduces developer error and enables external developers to simply pick up an object and complete the work. Without relying upon 1 single person who knows the solution, the solution becomes defused.
Think of it this way. An elephant is a large animal. I am a person, rather small in comparison. How would a person (small) eat an elephant (huge)??? Cut the elephant into bites. Once all the bites have been consumed and you put them together, a person (small) has eaten an elephant (huge). The key to success is to instantiate.

 

[KnutHandsome]

Re: KnutHandsome R U Knutts??

Why did you turn down a position because it used ADM 2?

I didn't. But it was a very powerful negative point against the job, purely because of my own prejudice, and gave me considerable pause for thought.

If you follow the ADM route, you KNOW where the bugs will be and where your code falls down.

That's a great selling point - perhaps PSC would be interested?
"Use our framework - it'll **** up your code!"

Think of it this way. An elephant is a large animal. I am a person, rather small in comparison. How would a person (small) eat an elephant (huge)??? Cut the elephant into bites. Once all the bites have been consumed and you put them together, a person (small) has eaten an elephant (huge). The key to success is to instantiate.

Wow! Those were the exact words which my current boss won me over with!

 

[KnutHandsome]

I really like the idea of this. I recently spent some time with Ruby On Rails.... "Creating a weblog in 15 minutes" presentation on the RoR site).

Yep, seen it some time ago, looks interesting. Learning it has the added benefit of being ahead of the curve, as it's one of those technologies that is starting to pick up momentum and support (assuming its not all hype).

Problem is, its more likely to have an impact on the Linux and MY-SQL environment, which I'm not terribly interested in.

I'm going to keep my eye on it though.

 

[mpowell_esq]

RE "Use our framework - it'll **** up your code!"

How can it do that? If you are using the framework You are applying the code, therefore YOU are doin the code that is ****** up, you are the developer. For **** up code you MUST be a poor developer.
The elephant analogy is know and used because it is simply true. Instanciate is the most effective method available. ONLY by instantiating are you able to improve. Priority is the solution, then once it is stable you are able to improve. Hence M$ & Windows, the product HAS NEVER been stable, so there has never been a chance to improve it. The same old hash keeps becoming churned out. Based origionally on the 9X kernal, then more 'FEATURES' / BUGS with the rewrite into XP and other.
The Progress product has been stable for a number of releases, now the OpenEdge advancement has made for the all round SOLUTION to Advanced Business Application Architecture.
p.s I should be working for PSC, I promote the excellent product whenever I can, which is always!!!