Openedge 11.6 - Visual Designer - Unable to resolve type in

Posted by doa on 10-Nov-2015 05:19

Hello,

I just updated to 11.6 and i can't seem to open any form in the visual designer that has a variable declaration for another form in the code.

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

I looked through the knowledgebase and tried everything i found but nothing helped.

I still get the error.

When i delete these variable declarations i can load the form.

Things i tried:

Class name and path case sensitive.

I have activated "Refresh using native hooks or polling" in the Workspace settings

I have set the class cache to "PROPATH"

Recompiling the whole project and restart Devstudio.

Does anyone have a solution for this problem?

Posted by Phani Sajja on 11-Nov-2015 23:34

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.

All Replies

Posted by Lars Neumeier on 10-Nov-2015 05:53
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.
Posted by Ramadevi Dhavala on 10-Nov-2015 06:01

Hi Doa,

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

DEFINE PRIVATE VARIABLE loTest AS test.TestForm NO-UNDO

Thanks,

Rama

Posted by Sanjeva Manchala on 10-Nov-2015 06:01

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.

Posted by doa on 10-Nov-2015 06:14

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

Posted by doa on 10-Nov-2015 06:17

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

Posted by Sanjeva Manchala on 10-Nov-2015 06:41

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.

Posted by doa on 10-Nov-2015 07:05

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

Posted by Sanjeva Manchala on 10-Nov-2015 07:16

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.

Posted by Laura Stern on 10-Nov-2015 08:00

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

Posted by doa on 10-Nov-2015 08:44

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

Posted by Simon L. Prinsloo on 11-Nov-2015 08:09

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.

Posted by Sanjeva Manchala on 11-Nov-2015 08:35
Hi,
 
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.
 
Posted by Ramadevi Dhavala on 11-Nov-2015 08:35
Hi Doa,
 
Please remove ‘.cls’ from the declaration. It worked for me.
 
PRIVATE VARIABLE loTest AS test.TestForm NO-UNDO.
 
Thanks,
Rama
 
Posted by Matt Baker on 11-Nov-2015 08:35
 
Remove the “private” part of the variable definition.  This might be triggering visual designer to treat it as a class field instead of just a straight variable and trying to pass it to .net which cannot load it.
 
Change it to this.
 
DEFINE VARIABLE loTest AS test.TestForm.cls NO-UNDO.
 
 
 
Posted by doa on 11-Nov-2015 08:58

@ 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

Posted by Simon L. Prinsloo on 11-Nov-2015 09:20

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.

Posted by Laura Stern on 11-Nov-2015 09:25

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.

Posted by Phani Sajja on 11-Nov-2015 23:34

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.

Posted by doa on 12-Nov-2015 02:37

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

Posted by Mike Fechner on 12-Nov-2015 02:40

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.

Posted by doa on 12-Nov-2015 02:56

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

At least it should be consistent.

Posted by Mike Fechner on 12-Nov-2015 03:00

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

This thread is closed