In follow-up, I think that I have the problem isolated to this function. This function is suppossed to re-group all nodes to their parents. Do you see any problems with this code that would cause such a crash?

---------------------------------------------------------------
Private Sub reGroupAll()
Dim gr1 As group
Dim x As Integer
Dim y As Integer
Dim bx As box
Dim pBox As box
Dim aTmp() As String

On Error GoTo reGroupAll_Error

'Destroy all groups
For x = FC(fcIdx).Groups.Count - 1 To 0 Step -1
Set gr1 = Nothing
Set gr1 = FC(fcIdx).Groups(x)
FC(fcIdx).DestroyGroup gr1
Next x

'Re-group everything
Set gr1 = Nothing
For x = 0 To FC(fcIdx).boxes.Count - 1
Set bx = Nothing
Set bx = FC(fcIdx).boxes(x)
Set gr1 = Nothing
If bx.OutgoingArrows.Count <> 0 Then
Set gr1 = FC(fcIdx).CreateGroup(bx)
If Not gr1 Is Nothing Then
For y = 0 To bx.OutgoingArrows.Count - 1
Set pBox = Nothing
Set pBox = bx.OutgoingArrows(y).DestinationBox
gr1.AttachToCorner pBox, 0
Next y
End If
End If
Next x

On Error GoTo 0
Exit Sub

reGroupAll_Error:
WriteErr "Error " & Err.Number & " (" & Err.Description & ") in procedure reGroupAll(line:" & Erl & ") of Form frmPreviewFCX"

End Sub
---------------------------------------------------------------

It crashes while the code executes. I've added logging into my application and it always crashes on this line:

gr1.AttachToCorner pBox, 0

Once in a while, it will actually complete the re-grouping, but as soon I click anywhere in the FCX control...CRASH! The FC_Clicked event never fires when the crash happens in this case.

It almost seems like the control is merely being overloaded. There's one more test that I'm going to perform and that is I'm going to turn off the BeginUndoRecord/EndUndorecord stuff to see if maybe the amount of actions being recorded is causing the failure.

In the meantime, I'm e-mailing the flowchart file.

Thanks,
Alan

Hi,

Have you set UndoEnabled = false, or just removed the Begin/EndUndoRecord calls?

Stoyan

Our developer has traced this to a CreateStreamOnHGlobal call returning E_OUTOFMEMORY. The process has only about 30 MB of memory allocated at that point, so we are not sure why that error would happen.

Our guess is that OLE might have some maximal number of memory streams that can be used simultaneously, and that number is reached when using composite undo records in your case.

In our test we have run reGroupAll() in a loop, using the diagram you have emailed us, and the error is returned for the 7th composite command. The previously saved composite records have 3396 constituent sub-records each. When not using composite commands, the records are discarded when UndoDepth is reached at 2000, so the error does not happen.

We will have to change the control to use some other memory allocation mechanism instead of OLE memory streams to work around this. For now, you could try using a small UndoDepth, e.g. allowing for only 3 or 4 composite commands to be recorded. That should ensure that the streams are disposed of before the limit is reached.

Stoyan

MergeUndoRecords creates a composite record too, so it won't help much.

Now the reGroupAll sub destroys all groups, then creates them again and attaches the nodes. You can considedrably reduce the size of the composite record by not recreating all groups, but only ones related to the tree branch that has been split. Otherwise you get a sub-record added to the composite for each DestroyGroup, CreateGroup and Attach method call (for more than 700 groups in the diagram you have sent us).

Stoyan