I might add that this also happens when you call CreateForm for two or more forms, where you call ShowModal (as in a user login form) before the first/main form is showing.

The ShowModal calls AppProcessMessages, and hence the events disappears before TApplicationProperties on the main form gets these.

Best regards,
Normann

Ah, this would seem to explain the reason why the OnDropFiles is never firing in my application.
I have about 15 forms between Application.Initialize; and Application.Run; and I've never mangaed to get it working under Mac OS X, even though I've followed the examples religiously. I also have a "Beta in progresss" form, that appears before the main form is displayed.

Any ideas?

Dominique.

"EarMaster - Bent Olsen" wrote

I might add that this also happens when you call CreateForm for two or

more

It seems like AEOpenDocuments event is processed, but since OnDropFiles event is not yet assigned, it's not fired.

So farm I can think of the following solution (in carbon widgetset). AEOpenDocument events and gathered and called on Application.Run, since form events are initialized and would be processed as expected.

thanks,
dmitry

How are the procedures on other platforms, for this situation? Doesn't Windows convert the dropped files into command line arguments?

If so, similar default processing could be implemented for MacOS - a default OnDropFiles handler, saving the filenames for later use.

DoDi

So is this now working as expected?

Dominique.

So is this now working as expected?

Yes and no.

It's working as expected from LCL point of view.
It doesn't work as expected from OSX point of view, because AEOpenDocument is used to start an application with opening some file. For other systems command-line parameters are used.

I'm not sure how to fix the problem, yet. So i far i can suggest not to use Application.ProcessMessages in component initialization.

thanks,
dmitry

When an application *can* be called with command line arguments, IMO a translation into such an argument is the best solution. When an application expects such arguments, it will check and process the passed arguments, regardless of how they have been supplied.

DoDi

I'd be in favour of Hans-Peter's solution until something more standard works.

This would at least allow things to work now, even if it is a workaround. As opposed to the current system, which only works in one case.

Remember it is not just the Application.ProcessMessages that is the problem.
It also occurs if you have more than 1 form between .Initialise and .Run

Dominique.

I'd be in favour of Hans-Peter's solution until something more standard works.

Carbon widgetset is not ideal in implementation, but i don't think that brining more "features" to it would make it better. The problem with converting AEOpenDocument to params is that you won't be able to see the difference, between real command params and generated by LCL.
If additional params are always generated and event is fired then application might make double-file openning or the app need some way to know what params are real.

thanks,
dmitry

Everyone interested, please test r22364

thanks,
dmitry

> I'd be in favour of Hans-Peter's solution until something more standard > works. Carbon widgetset is not ideal in implementation, but i don't think that brining more "features" to it would make it better.

Think about multi-platform applications. Lazarus/RTL/LCL should offer one unique way to deal with dropped files on app start, independent from the target platform. Since it's impossible to distinguish commandline arguments from dropped files on other platforms, special handling is possible only for Carbon, in dedicated Carbon applications.

When the event is not handled (Message.Result), the default handler (TApplication.WndProc?) can do whatever seems to be appropriate. On Carbon it can set a flag, in addition to converting the dropped files into commandline arguments. Also Application.Run can try to send the message once more, but this makes things more complicated (when the command line arguments already have been processed by the application...).

A TApplication.OnOpenDocument handler can be introduced, which can be implemented by an application, or a flag can indicate how things should be handled.

DoDi

Hans-Peter Diettrich wrote

Think about multi-platform applications. Lazarus/RTL/LCL should offer one unique way to deal with dropped files on app start, independent from the target platform.

I can think of Mac OSX only that's able to start application by dragging a document to the application's shortcut (at the dock). AFAIK, Windows (even Win7) doesn't have such ability. So, it's to early to talk about cross-platform behavior.

The bug has been fixed in the revision given in my previous email without additional workarounds. The problem was caused by incomplete event loop initialization.

A TApplication.OnOpenDocument handler can be introduced, which can be implemented by an application, or a flag can indicate how things should be handled.

Yes, that would be a good solution.
Infact, using OnDropFiles is incorrect event for handling "startup open-files" and has been introduced for OSX system compatibility. Dropping files (dragged from Finder) on a form is not yet implemented for Carbon.

thanks,
dmitry

The same for Windows and Linux (at least KDE). Drop files from the Explorer on any application icon on the desktop...

DoDi

Hi Dmitry,
This seem to work for me. I need to do a bit more testing, but so far it is behaving as expected.

Dominique.

dmitry boyarintsev wrote

Everyone interested, please test r22364 thanks, dmitry

Hi dmitry,

I made a small simple test app with latest snapshot of Lazarus/FPC, with two forms, one with TApplicationProperties and OnDropFiles, and the second showing as modal before .Run - it seems to work as it should.

Thanks, and best regards,
Normann

EarMaster - Bent Olsen wrote

I made a small simple test app with latest snapshot of Lazarus/FPC, with two forms, one with TApplicationProperties and OnDropFiles, and the second showing as modal before .Run - it seems to work as it should.

Normann, could you public the projects?
or create a bug report and attach samples there?

thanks,
dmitry

A bug report? Even if it seem to work? :-)

My small test project is very simple - I just create a new empty project, add a new empty form "Form2", beside the default "Form1", and add TApplicationProperties in Form1 and assign OnDropFiles which just sets the forms Caption := FileName[0], and in the project source I add Form2.ShowModal:

begin
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.CreateForm(TForm2, Form2);
  Form2.ShowModal;
  Application.Run;
end;

When you close Form2, the Form1 should appear and have its caption set to a file name, if you drag a file to the application icon on the Dock - a shortcut to the projects application needs to be on the Dock.

This code did not work before the fix, but it seems fine now.

Best regards,
Normann