dormky

This is related : https://stackoverflow.com/questions/4652958/is-there-a-way-to-log-every-gui-event-in-delphi I wrote this unit based on it, it might give you ideas. Note that this is not perf-tested and is probably quite bad in that regard with all the looping of rtti info. Also might crash if you have cases I have not covered when interpreting RTTI. unit UEventLogger; // See https://stackoverflow.com/questions/4652958/is-there-a-way-to-log-every-gui-event-in-delphi // Call TEventLogger.AddEventInterceptors in every FormCreate. // Since TEventLogger is a compnent, it gets destroyed when his parent gets destroyed. interface uses EEvents, EException, Classes, Controls, Generics.Collections, Rtti; type OnEventLoggerEvent = reference to procedure(const event: string; const controlName: string); TEventLogger = class(TComponent) private EventName: string; originalEvent: TNotifyEvent; procedure HandleEvent(Sender: TObject); constructor Create(Control: TControl; EventName: string; originalEvent: TNotifyEvent); class procedure RecurseControls(Control: TControl; ExaminedControls: TList<TControl>; context: TRttiContext); public class procedure AddEventInterceptors(Control: TControl); class procedure RegisterEurekaLogWriter(); class var logs: TArray<string>; class var OnEvent: OnEventLoggerEvent; end; implementation uses TypInfo, SysUtils, Windows; type TStupidEL = class procedure OnReproduceRequest(AExceptionInfo: TEurekaExceptionInfo; var AReproduceText: String; var ACallNextHandler: Boolean); end; var h: TStupidEL; constructor TEventLogger.Create(Control: TControl; EventName: string; originalEvent: TNotifyEvent); begin inherited Create(Control); self.EventName := EventName; self.originalEvent := originalEvent; end; procedure TEventLogger.HandleEvent(Sender: TObject); begin // Log the event : datetime - event name - control name logs := logs + [FormatDateTime('dd/mm/yy hh:nn:ss.zzz', Now()) + ' - HandleEvent ' + EventName + ' on ' + (Sender as TControl).Owner.Name+'.'+(Sender as TControl).Name]; if Assigned(OnEvent) then OnEvent(EventName, (Sender as TControl).Owner.Name+'.'+(Sender as TControl).Name); // Forward to the original handler originalEvent(Sender); end; class procedure TEventLogger.RecurseControls(Control: TControl; ExaminedControls: TList<TControl>; context: TRttiContext); var theTypeInfo: TRttiInstanceType; theProperty: TRttiProperty; interceptor: TEventLogger; theEvent: TNotifyEvent; theValue: TValue; field: TRttiField; newControl: TControl; instanceType: TRttiInstanceType; begin ExaminedControls.add(Control); theTypeInfo := context.GetType(Control.ClassInfo) as TRttiInstanceType; for theProperty in theTypeInfo.GetProperties do begin if (not theProperty.IsWritable) then continue; if (not (theProperty.PropertyType.ToString.StartsWith('TNotifyEvent'))) then continue; if (theProperty.Name = 'OnClick') or (theProperty.Name = 'OnDblClick') then begin theValue := theProperty.GetValue(Control); theEvent := nil; if not theValue.IsEmpty then theEvent := theValue.AsType<TNotifyEvent>(); if Assigned(theEvent) then begin interceptor := TEventLogger.Create(Control, theProperty.Name, theEvent); theProperty.SetValue(Control, TValue.From<TNotifyEvent>(interceptor.HandleEvent)); end; end end; try for field in theTypeInfo.GetFields do begin if field.name.StartsWith('F') then continue; // All the private F fields ; we're only interested in our boutons and things like that. if field.FieldType = nil then continue; // Undefined types, like pointers (^TQCTestAll) if field.FieldType.TypeKind = tkClass then begin instanceType := field.FieldType As TRttiInstanceType; if instanceType.MetaclassType.InheritsFrom(TControl) then begin newControl := nil; theValue := field.GetValue(Control); if not theValue.IsEmpty then newControl := theValue.AsType<TControl>; if Assigned(newControl) then if not ExaminedControls.Contains(newControl) then RecurseControls(newControl, ExaminedControls, context); end; end; end; except on E: EAccessViolation do // For some reason we can get an AccessViolation while looping through the fields. Seemed to happen // on ParentControl. end; end; class procedure TEventLogger.AddEventInterceptors(Control: TControl); var examinedObjects: TList<TControl>; begin examinedObjects := TList<TControl>.Create(); TEventLogger.RecurseControls(Control, examinedObjects, TRttiContext.Create()); examinedObjects.Free; end; procedure TStupidEL.OnReproduceRequest(AExceptionInfo: TEurekaExceptionInfo; var AReproduceText: String; var ACallNextHandler: Boolean); begin AReproduceText := sLineBreak + String.join(sLineBreak, TEventLogger.logs); TEventLogger.logs := []; end; class procedure TEventLogger.RegisterEurekaLogWriter(); begin RegisterEventReproduceRequest(h.OnReproduceRequest); end; end.

If you're open-source, you need to sell something else (training, resources, support, etc...)

I'm 100% agreeing with you. Management doesn't. Management wants a pretty loading icon without actually putting in the work 🙂 Imo the windows cursor does a perfectly fine job, we're talking ~10s loading time here.

I thought about this, but dismissed the idea as this would mean the loading gif is dissociated from the window in which the loading occurs. If the window gets resized, moved, minimized or simply if the user opens up another program in that screen space that form is in trouble (ie will not be kept visible only when the working window is visible, and centered within it).

Going around a bunch of files inserting calls to ProcessMessages in mostly random places (the work is not deterministic) seems like a magnificient way of shooting both feet at the same time 😕

I've tried calling Application.ProcessMessages from a thread, that didn't work. Had to try it lol. My goal is to have a loading gif playing while the work is ongoing. The work cannot be moved out of the main thread, as this would require rewriting multiple thousands of lines of code, which is sure to create bugs (especially as this deals with COM ports). Any ideas ?

For most cases, I would recommend using the delphi-provided libraries instead of rolling your own, see https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Math.InRange

To note ; the OnFormClose event isn't called when calling Close. However I just discovered there is a CloseModal function, which doesn't set the ModalResult to cancel in the case where the form is modal. It does set ModalResult to 0 in the case where the Action is set to caNone. Again, just a badly designed API. OnFormClose should be called no matter how you close the form. There shouldn't be 3 separates ways of closing the form, there should be one (taking arguments if you do want to manipulate some behavior). And said way should not be manipulating the value I want to return to the caller, as that is app data. This is like having 3 locks on your door, each looking the door in a different way and you can only lock one at a time. Also the second and third lock each turn on a different porch light when you use them after 22:00.

Sure, and using assembly is logically identical to using C. But for the vast majority of purposes one has a better API wouldn't you say ? Bit of an overkill comparison, but the point stand. The Windows API in this case is better than the Delphi one for reasons already outlined.

If they implemented it in the same way (a single flag serving two purposes), I would levy the same critique. With the caveat that it least it doesn't make the API more confusing since it's internal. Whereas as far as I'm aware, Delphi had no obligation to implement it in the same way, although it might have been a volition at the time to do a one-to-one of Windows. Which could be critiqued in itself, of course.

Yes, and I established that it does it _internally_ and that you don't have a single flag serving two purposes, as you do in Delphi.

Depends on the project of course, and secondarily on my current skillset. For the project that spawned this thread, I probably would have gone with WPF, which would have given me easy access to the .NET ecosystem which would be useful since there's a lot of places with custom drawing, while the rest of the interface is very basic.

Of course, I never would have chosen Delphi for a new project. But there's a lot of old 90's projects out there for which it's not cost-effective to move to a more efficient platform, so Delphi sticks around.

By implementing your own ShowModal which doesn't rely on it and instead listens for a "close" event, I suppose. Maybe you could make a "Close" function which would raise this event and set the return value to the value given by argument... You know, just how EndDialog does it 😉

Hey, bad design doesn't mean it's not useful. I still use a car whose AC is less powerful then a fart lol.