Disabling "Generate event procedure" deletes event procedure in already existing form with event procedures?

[Nudgy]

Hi,

I was wondering if the following is the intended behaviour of the PureBasic form designer?:

If I disable "Generate event procedure" in File -> Preferences -> Form, this seems to also delete the an existing event procedure in the form that is currently being edited, even though this form already has an event procedure (for example the "Procedure Window_0_Events(event)" part). This seems to happen even if I have checked "Generate events procedure?" in the form properties.

I think a logical behaviour for disabling "Generate event procedure" in PureBasic settings, should be that event procedure generation is justed "unchecked" in future/new form properties by default, not that existing events code is wiped in the form designer.

Because if disabling "Generate event procedure" also makes changes to already made forms, it would be difficult to have different projects that use different event handling methods (e.g. some projects using BindEvent(), some using event loops, some using EventDesigner etc.).

Am I misunderstanding something, or is the PureBasic Form Designer behaving correctly? I do like the automatic event procedure generation for simpler projects, but I wouldn't use it for all projects.

[spikey]

Is the PureBasic Form Designer behaving correctly?

The form designer is behaving as it is programmed, yes. Is the behaviour you're describing desirable in a perfect solution, probably not.

Am I misunderstanding something?

Probably. The form designer doesn't maintain the code directly, it parses the incoming code when the file is opened into an internal data structure. Those structures are maintained as you modify the form design. It then generates a completely new code based on those structures and the current IDE preferences when you save it (or switch to the code view). It's this behaviour that is causing what you see.

The form designer was originally a separate application from the IDE so its parser isn't nearly as sophisticated as the IDE source code parser.

[Nudgy]

Thanks for your answer.

After some more testing, I think this maybe works alright. If I understand the "Generate event procedures" setting in Preferences (not the similarly named setting in the form designer) it actually works as follows:

1. If enabled in Preferences -> An event procedure will be generated in the form code, but only if there is also a checkmark in the corresponding "Generate event procedure?" within the main Form properties.

2. If disabled in Preferences -> No event procedures are ever generated in the form, and if you use the form designer to make changes to an existing form, the existing, auto-generated event procedure in the form code would be deleted.

So I guess that generally leaving the "Generate event procedure" on in Preferences, might be the safest option no matter how events are handled in a project, since then only the form Properties for the specific project would be used to toggle event procedure generation on and off. This would also prevent the accidental wiping of the form event procedure when switching between projects that use or don't use the automatic event procedures. But I haven't tested this extensively.

[TI-994A]

...if disabling "Generate event procedure" also makes changes to already made forms, it would be difficult to have different projects that use different event handling methods...

I would believe that this is a somewhat buggy behaviour, because as you said, it could break projects that were dependent on their forms' event procedures.

But this would happen only if the code pages of those form files were re-opened when the generate-events option has been disabled at the app level, because doing so would essentially delete any event procedures in those files, automatically, and without warning.