progress 8 -> openedge 10.1 compiler looks for classes?

Posted by steven.post on 24-Sep-2008 07:50

Hi,

I'm fairly new to Progress and OpenEdge, but now I'm working on my first big project. Upgrading an application from Progress 8(originally 6) to OpenEdge 10.1c.

There are some fill-in fields in a GUI that have the same name as database fields, such as customer.customer. In progress 8, this doesn't pose a problem, but in OE10.1c the compiler gives an error:

Compiling someguiprocedure.w

Could not find source class file factuur\factuur.cls. (12625)

I found out that the error is situated when the customer.customer:screen-value is assigned in the code (using the assign keyword).

I managed to fix the following situation:

1) find something in DB

2) ASSIGN customer.customer:screen-value = customer.customer.

this is solved by using "display customer.customer with ."

But how do I fix the following assignment?

ASSIGN customer.customer:screen-value = somelocalvariable.

In boh cases of using the screen-value, the compiler complains about not finding the file customer/customer.cls (which of course doesn't exist as it's progress 8 code)

Any help is appreciated.

sincerely,

Steven

All Replies

Posted by Tim Kuehn on 24-Sep-2008 13:29

try using

customer.customer:screen-value in frame frame-name = somevariable.

or

frame frame-name customer.customer:screen-value = somevariable.

I one of those forms'll do what you want.

Strange about the complaint about the missing class though.

Posted by jtownsen on 24-Sep-2008 15:29

Another alternative could be to wrap a section of code with "DO WITH FRAME : ... END." This approach is handy if you've got lost of problem statements.

Posted by Admin on 24-Sep-2008 20:16

Extent you current workaround "display customer.customer with ." to fit the "somelocalvariable" exception, try

"display somelocalvariable @ customer.customer with ."

Be careful of using , event triggers should be fine but you may run into issues within internal procedure/functions ... especially in procedures which have multiple frames.

Posted by steven.post on 25-Sep-2008 02:08

Thanks for the help guys, I just noticed an error in my original post, the missing class is the same as the name of the field, so that wou be customer/customer.cls instead of factuur.

Anyhow...

@ Tim: whatever I try, as long as I use the screen-value attribute the missing class error pops up.

@ Jamie: The problem occurs in a trigger (perhaps not exlusivly, but in this case all "customer.customer:screen-value" statements are in triggers. These triggers are already completely wrapped in a do with frame statement, so that wouldn't be the solution.

@ Colin: Thanks, you pointed me in the right direction, when I add the "with frame" statement as in your code, I get errors on the syntax check, but it works just fine without (the whole trigger is in a do with frame block, so I don't think it really matters).

I now use "DISPLAY somevar @ customer.customer." which seems to be working fine.

On a final note, the original code with screen-value does seem to work, but gives the errors about missing classes. Apart from that, there doesn't seem to be a difference now.

Message was edited by:

Steven Post

Posted by steven.post on 25-Sep-2008 04:22

ok, I've managed to get rid of a lot of these class related errors, but I still see some and these don't seem to have a "customer.customer:screen-value" statement at all.

So any ideas are still welcome.

Edit: for some odd reason, this problem doesn't show missing 'product/product.cls' files... yet uses the same type of code...

Message was edited by:

Steven Post

Posted by rstanciu on 25-Sep-2008 06:10

In my opinion, if you want to don't loose your time, you have to modify in the

database the field named "customer.customer" to something like:

"customer.customerNew". Recompile all the application, check the errors

and replace all "customer.customer" by "customer.customerNew".

Posted by steven.post on 25-Sep-2008 06:28

I'd rather not do that, since it's a pretty big application, with many different subapplication, some of them give that error, not all, so I think it's easier to change the name of the fill-in field in those few applications.

Posted by jtownsen on 25-Sep-2008 10:26

In my opinion, you should definitely be talking to Tech Support (if you aren't already).

Please let us know if you find out anything interesting there.

Posted by Thomas Mercer-Hursh on 25-Sep-2008 10:57

The problem occurs in a trigger ...

I now use "DISPLAY somevar @ customer.customer." which seems to be working fine.

Does this mean you have user interface statements in a trigger?????

Posted by Tim Kuehn on 25-Sep-2008 11:03

The problem occurs in a trigger ...

I now use "DISPLAY somevar @ customer.customer."

which seems to be working fine.

Does this mean you have user interface statements in

a trigger?????

UI statements in a UI trigger are perfectly appropriate.

They don't belong in a db trigger though....

Posted by steven.post on 26-Sep-2008 04:36

Yes.. These are UI statements in a UI trigger, why would anyone write UI statements in a DB trigger anyway? Seems illogical to me but then again.. I've seen some weird things in this application^^

Back on the subject, I'll let you guys know as soon as I've got more info on this. (probably somewhere next week, due to my lack of time)

Posted by steven.post on 09-Dec-2008 03:32

I'm sorry it took so long to update the status on this one, slipped my mind.

This 'bug' seems fixed in one of the service packs for OE 10.1c, running a OE 10.1c SP2 doesn't reproduce this.

This thread is closed