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