Orchestration debugger and large orchestrations

[Mark]

Hi,
I have been devloping an orchestration which is now humongous :-(
Are there limits to the size of an orchestration? Are there limits to the
size the orchestration debugger can show?
I get endless exceptions thrown:

************** Exception Text **************
System.ComponentModel.Win32Exception: The operation completed successfully
at
System.Windows.Forms.DibGraphicsBufferManager.CreateCompatibleDIB(IntPtr hdc,
IntPtr hpal, Int32 ulWidth, Int32 ulHeight, IntPtr& ppvBits)
at System.Windows.Forms.DibGraphicsBufferManager.CreateBuffer(IntPtr src,
Int32 offsetX, Int32 offsetY, Int32 width, Int32 height)
at System.Windows.Forms.DibGraphicsBufferManager.AllocBuffer(Graphics
targetGraphics, IntPtr targetDC, Rectangle targetBounds)
at
System.Windows.Forms.DibGraphicsBufferManager.AllocBufferInTempManager(Graphics targetGraphics, IntPtr targetDC, Rectangle targetBounds)
at System.Windows.Forms.DibGraphicsBufferManager.AllocBuffer(IntPtr
target, Rectangle targetBounds)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)

Are there any configuration settings that could increase any limites I'm
bumping into?

thanks

m

[Peter Dol]

Hello Mark,

you can split your orchestration up into several smaller orchestrations.
You can call these from the "mother orchestration" with a call orchestration
shape.
This way you will avoid running into these limits. It will improve maintainability
too ; D

[Mark]

Peter,

thanks - I will do that but the problem has gotten worse and the
orchestration designer can't cope with it now either.

Have others used Large orchestrations? there are no documented limits.

[Peter Dol]

Hello Mark,

If you are still stuck, you could try to edit the orchestration manually
by opening it in notepad. Then you could try to chop it up in smaller pieces.
You can remove the generated code after the second __DESIGNER_DATA. This
code will be generated again if you open the chopped orchestrations in visual
studio and edit something.

Be sure to make a backup of your original odx though!

[Mark]

As suggested by Peter, the solution to this problem is to break the
orchestration down into a series of called orchestrations.

In case anyone else runs into this problem.
Although there are no published limits to the size of Orchestrations, there
most certainly are limits. When you hit this limit, you don't get any direct
warning instead things just start to fail. Compiling and running large
orchestrations works just fine but the gui tools (Orchestration Designer and
Orchestration Debugger) fail in unpredictable ways.

The first sign you are in trouble is when the orchestration designer does
not draw all links, instead you have to start clicking on things to get them
drawn. It is as though the designer realises it is in trouble and starts a
resource conservation regime.

The second stage is that orchestration debugger takes an age to draw and
then throws a series of exceptions: Win32Exception: operation completed
successfully. Initially you can click thru these and still debug but
eventually that gets tedious.

The third stage is that the orchestration designer throws the same
exception. It can confict with the drawing of (say) the toolbox and appear to
put the process into a loop. From here on it is tricky to do anything.
The Orchestration designer will start to claim the orchestration file is
corrupt. When you compare the current version with what's in sourcesafe it
does appear to be corrupt. However when you exit Visual Studio and re-start
it the corruption appears to be fixed.

I guess the moral of the story is - if you need a whole wall to display the
entire orchestration - it's time to re-factor.

m