microsoft / automatic-graph-layout

A set of tools for graph layout and viewing
Other
1.36k stars 304 forks source link

LayoutSettingsForm Dialog won't close #255

Closed kinahawi closed 4 years ago

kinahawi commented 4 years ago

When running the sample code, if I bring up the LayoutSettingsForm using and modify any of the properties (e.g., changing RerouteOnly from false to true), the dialog can not be closed. Debugging shows close call within okButton_Click in LayoutSettingsForm.cs is being called, but there is no effect. Also unable to edit any more properties in the PropertyGrid brought up by the form. Set my debugger to catch all exceptions, but none are reported.

levnach commented 4 years ago

I am not sure how to fix it. It used to work but some external to MSAGL change causes a lock.

kinahawi commented 4 years ago

Lev,

I am running into a similar problem when using the SaveFileDialog in my app. The modal prompt for overwriting the existing file is hidden somehow and this prevents me from doing anything else in the app. During debug, I did find that the OnPaint method in the DrawingPanel is called constantly despite the fact the region does not need to be repainted. OnPaint is only called this way when there is a graph. When there is no graph, everything works just fine. I suspect the constant painting is contributing to the problem.

I noticed the same thing happens when using the SimplestWinFormsSample. OnPaint is called repeatedly even though there should be no need to repaint. Maybe this is the same problem with the layout settings modal dialog?

Thanks,

Bill

levnach commented 4 years ago

Sorry, I have no time to look into it now. I wonder if a similar problem was reported in WinForms in other settings than Msagl.

kinahawi commented 4 years ago

OK, after some time spent debugging, I've isolated it to the calls to GViewer.BackwardEnabled and GViewer.ForwardEnabled made by HandleViewInfoList which is called by the GViewer ProcessOnPaint method. Turns out that BackwardEnabled and ForwardEnabled modify the bit maps of their associated toolbar buttons which causes Windows to want to paint again which triggers an infinite repaint loop. For now, I've commented out the calls to set BackwardEnabled and ForwardEnabled because the buttons still work and I really don't care what they look like. If you have a preferred way to fix it, give me some direction and I'll try to take care of it for you (although the value of this feature is not clear to me).

This does address the issue with modifying the layout using the layout settings dialog.

Bill

levnach commented 4 years ago

Thank you very much, @kinahawi ! Can you check please that my last push fixes it?

kinahawi commented 4 years ago

Yes, that seems to have fixed the problem. Thanks for spending time on this!

Bill