Today I wanted to do something I did before: Add a drop file handler to an edit control in a dialog of the Delphi IDE. The dialog in question is the the Project Options dialog.
Today I wanted to do something I did before: Add a drop file handler to an edit control in a dialog of the Delphi IDE. The dialog in question is the the Project Options dialog.
I thought it would be pretty simple to do that:
Get the dialog instance from Screen.Forms list.
Get the edit control using the form’s FindComponent method
Attach a drop file handler to it.
Pretty standard for somebody who has written IDE plugins for Delphi before and is somewhat acquainted with its internals. Little did I know how difficult it would become.
http://blog.dummzeuch.de/2015/10/11/hacking-the-delphi-10-project-options-dialog/
I thought it would be pretty simple to do that:
Get the dialog instance from Screen.Forms list.
Get the edit control using the form’s FindComponent method
Attach a drop file handler to it.
Pretty standard for somebody who has written IDE plugins for Delphi before and is somewhat acquainted with its internals. Little did I know how difficult it would become.
http://blog.dummzeuch.de/2015/10/11/hacking-the-delphi-10-project-options-dialog/
If two or more plugins hijack the same global event handler then they must restore the previous (from their point of view) handler in reverse order, however this is not guaranteed and therefore this technique is likely to cause trouble.
ReplyDeleteOndrej Kelle I know, the IDE explorer crashed my IDE multiple times because of that. GExperts already used that handler, so I didn't actually add any additional possibly cause for trouble. Do you have any suggestion on how to prevent this?
ReplyDeleteAPI should be written, safe for plugins to use instead of the event handlers.
ReplyDeleteThomas Mueller Regarding your TCustomComboBox cast - I think you don't need to gamble: just do the usual TCustomComboBoxAccess = class(TCustomComboBox ) trick.
ReplyDeleteUli Gerhardt Yes, I could have done that, but basically casting to TComboBox does the same as long as I only access the Text property.
ReplyDeleteThis scenario remembers me when I wrote interrupt handlers for DOS. The civilized way was to hook and return the original handler, except when you replace the interrupt, in that case you was obliged to expose the original interface, just to not broke something else. Something similar must be done with IDE plugins, otherwise it will become bad coding.
ReplyDeleteHeinz Toskano I remember something similar from my Atari ST hacking times: There was a standard how a chain of interrupt handler pointers must be built. My memory is rather fuzzy, but it required a magic number to be stored near the destination memory address and also the original value stored there.
ReplyDeleteWe could try and define something similar for IDE plugins, but would others really adhere to it? Maybe if Embarcadero (or whoever will be the one who decides over the future of Delphi) proposed and documented it...
Thomas Mueller that's the main problem, many developers are working blind, as there is no documentation at all or it is very poor. My first interrupt handlers were fuzzy and prone to hang up all the system, until I found how to do it the right way. But that was a very long process of trying and failing. Seems we are repeating history, this time in the form of IDE addons.
ReplyDelete