Setting a property - Building workspace hangs at 14%

Posted by rbf on 29-Dec-2011 03:07

We have added a property to our ToolbarsManager called ActionTable that shows up in the Visual Designer. If you edit it the SETter fires a dialog that allows you to edit a table of data (these are additional properties for the Tools on the ToolbarsManager). The result is stored as a JSON string in the property ActionTable. This all works fine, until you save the (now modified) source. Then the Visual Designer always hangs at "Building workspace: (14%)". The only way to resolve this is to restart the OpenEdge AVM.

It was suggested that an endless loop was created in this way so I added another property, a logical called ActionTableToggle, that can be doubleclicked to fire the abovementioned dialog. However no change in the described behavior.

I have added 4GLTrace logging and there is no endless loop. The AVM simply stops at the execution of a statement that looks harmless.

This is of course in a very complex environment so I have not yet tried to isolate problem in a reproduction for Tech Support. Before I go down that road I was wondering if anyone has seen this behavior before, knows what the 14% means and how I can solve this.

OpenEdge Development - Forum

All Replies

Posted by rbf on 29-Dec-2011 08:50

Two additional observations that might ring a bell to somebody:

  • The problem can also be solved by closing the form that hangs (without saving). The modified source code has been saved to disk already, so when the form is reopened the changes are there. We just need to save it again in order to compile it. At that time both the new .r and .resx files appear on disk.
  • The JSON string is actually written to the .resx file (automatically since it exceeds a certain size). That may be significant.

So it seems the hang occurs between saving the source and compiling it?!?

Posted by Matt Baker on 29-Dec-2011 20:34

Check the generated code for really complex nested expressions.  The compiler (and OEA) can get stuck when there are somewhere around 21 nested expressions 

variable = call(call(call(call(..21x..)))).

The VD tries to avoid this scenario by splitting these up, but there may be cases where this doesn't happen.  This might not be your case, but something to check.

Posted by rbf on 02-Jan-2012 02:12

Hi Matthew,

Thanks for your answer. I checked and doublechecked the code but I don't see any really deep nested expressions.

Can you give any indication what the VD is doing when it displays "Building workspace"? I suppose compiling, but that should not be the problem. I suspect the problem is in some housekeeping just prior to that.

Posted by Matt Baker on 03-Jan-2012 07:48

Not without turning on tracing or with a debugger.   Mostly it spends its time deleting r-code, updating the class cache when necessary, removing resource annotations and calling the compiler.  There isn't anything special about the number 14%. 

Posted by Peter Judge on 03-Jan-2012 08:04

There isn't anything special about the number 14%.

It's a third of 42?

-- peter

Posted by rbf on 03-Jan-2012 08:32

You are both right, the number can vary, I noticed that in another project it is always 28%.

The good news is that yesterday I have been able to create a reproduction (where the number is 0%!) and submitted it to Technical Support.

They now have confirmed that they can reproduce it in 10.2B05 and are working on it.

-peter

This thread is closed