Openedge 11.6 - Visual Designer - Unable to resolve type in

DEFINE PRIVATE VARIABLE loTest AS test.TestForm.cls NO-UNDO. 

is wrong.

DEFINE PRIVATE VARIABLE loTest AS test.TestForm NO-UNDO. 

is the correct syntax.

Hi Doa,

Please remove '.cls' from the variable declaration. It worked for me.

DEFINE PRIVATE VARIABLE loTest AS test.TestForm NO-UNDO

Thanks,

Rama

Hi,

In addition to the above I would like to add the following:

We have seen similar issue when casing package name is different than the one mentioned in the variable declaration inside another. Changing the casing of package name to actual name and then cleaning the r-code solves the problem.

Hope this helps,

Sanjeev.

Oh sry the .cls was just a copy paste error, i defined it without .cls in the code.

@Senjeev I will try to recompile the whole project

Ok i deleted all *.r Files, triple checked all the casings, but i still get the same error

Hi,

Cay you please try by closing all the opened Forms in PDS OE editor view.

Have you deleted the .r files manually or you invoked clean operation on the project? If you have deleted manually please try to invoke Project > Clean... and then restart PDS OE and then try to Open the Form.

Hope this helps,

Sanjeev.

I cleaned the project and restarted everything...still the same error :/

Hi,

Can you please share your project, so that we can look into that for any specific scenario it's causing failure. Otherwise please a report a case with Technical Support with reproducible files.

Thanks,

Sanjeev.

Sorry if you said this somewhere but I don't see it.  What error message are you actually getting?

I get the error "Unable to resolve type information for type <test.TestForm> for field oTestForm

oTestForm ist my Variable that is defined in the class

This message often indicates that the constructor of test.TestForm has thrown a runtime error when the designer tried to instantiate it.

Put a catch block in the constructor and message the error before throwing it again. Be aware that the message box may pop up behind Eclipse, so it will seem as if it is not responding while it waits for the AVM, which is waiting for you to OK a message that is behind Eclipse.

Remember to remove the message in the constructor once you resolved the root cause.

@ Sanjeev: The casing is correct, still the same error

@ Matt: Made no difference

@ Simon: The constructor didn't threw any errors

The strangest thing is, I completely cleared the referenced class, it is just an empty class now...and i still get this error

You can try this:

Close the designer view and open the source of your class and make sure you have focus on that file.

Restart the AVM to make sure you flushed any problems caused by the failure to start the designer.

Click the "Procedure Editor" button in the toolbar. That will launch a procedure editor in the same AVM used by the designer. It will also open the file you have open. Close the file. We need an empty editor and do not want to overwrite the current file by accident.

Switch on logging for the AVM like this:

LOG-MANAGER:LOGFILE-NAME = SESSION:TEMP-DIR + "\designer.log".
LOG-MANAGER:LOG-ENTRY-TYPES = "4GLTrace:3,4GLMessages:2".
LOG-MANAGER:CLEAR-LOG().

Note that the editor is cripple, it will delete the last character of the line when you press ENTER, so always add a space to the end of the line before you press ENTER, or write the code in another editor and copy and paste it.

Hit F2 to run the above code. You can close the editor or keep it open. I keep it open, because I need it again to switch off logging.

Now open the designer and wait for it to crash.

Go back to the "cripple" editor and run this code to switch off logging.

LOG-MANAGER:LOGFILE-NAME = ?.

Open the log file in any decent editor. You can message SESSION:TEMP-DIR in the same editor if you do not know where the file is.

Search for "ERROR" in caps and without quotes from the top of the file. The first occurrence should be at the end of a line that will most likely start with "Return from", followed by a method name and the class name of the method in square brackets.

The method that returned the ERROR will be the cause of your problems.

If ERROR does not occur at all, I am at a loss.

If it occurs for the first time on another line, it should still point towards the root cause.

That is not so strange.  Based on the error message you are getting and the fact that the code DOES compile, this is a tooling problem - not an ABL issue.  Clearly there is something amiss in the PDSOE environment that it cannot access the class information.  So it doesn't matter if there's any information in the class or not.  It is not able to access it at all to see what is in there.  Did you try bringing up the object browser?  I'm guessing that won't work right either.

If you add this same class file into another new project, can you open it in VD from there?  Is it only references to other Forms that doesn't work?  What about other types of classes?  Is it references to any class that inherits from a .NET class?  Just fishing for something that will narrow things down.

The issue might occur in the following cases:

  1. You have a class's package in one case and being referenced in different case.

       com.progress vs Com.Progress

  2. You have diferent classes fall into the same package with different cases.

       com.progress.ClassA, com.Progress.ClassB

The issue got fixed after 11.6 is out.

Check the case of the package and the one in the class definition and the references made it.

If you can share the project, we can figure out the exact problem of this.

--

Regards,

Phani S.

Ok that was it, thank you.

I replaced the full package name with the right casing in the whole project, rebuilt it and now the Form opens.

Thats a pretty heavy bug....

OpenEdge programmers are pretty much spoiled by ability to ignore casing.

In .NET casing counts! With GUI for .NET you become a .NET programmer - so regardless of what Progress can do to relax this in the tooling, you better get used to exact casing. Sorry - I know this is annoying.

The problem here is that the compiler doesn't care for the casing but the visual designer does.

At least it should be consistent.

Agree with the need for consistency.

But trust me ... there are cases when the compiler cares as well. He's just a little more forgiving....