/g:options.txt and spawning from dir to file comparison

j_hoppe · Post by **j_hoppe** » Fri Jul 22, 2005 2:54 am

I use ExamDiff Pro embedded as part of another application.
I need to use a hand prepared set of options,
so I use the /g-Options in the command line, when I
call ShellExecute().
I start ExamDiff in "dir comparison" mode, but if a new instance of ExamDiff is started to compare a single pair of files, it seems that
the new instance is not called with my /g:-options.

So I can not prepare some file comparing options for my users, when I
first call a directory comparision.

Did I overlook something?
If not, I think there are two solutions to fix this:

a) the spawned instance should be called with the same commandline options as the first instance.
OR
b) command line options should be stored immediately in the registry
(and not only after altering some options manually), so the spawned instance uses them too.

Thanks for caring!

Post by **psguru** » Fri Jul 22, 2005 3:39 pm

This is a valid point. Option b) is not good since many EDPro users depend on the existing behavior. Option a), however, seems to be the right one. EDPro should indeed pass all options to spawned file comparisons.

There are three ways to specify command line options for EDPro:

(1) using specific command line options (such as /i)
(2) using an entire options file (/g), in which case specific options are ignored
(3) using /se option to specify a session whose options will be used (in this case (1) and (2) are ignored).

EDPro currently does pass current session to spawned file comparisons (so case (3) is covered). It does not, however, pass options specified in the command line using (1) or (2).

One solution could be as follows: when a file comparison is spawned from directory comparison, EDPro will save current options to a temporary options file and then use option /g with the temp file when the new process is started. The temp file will then be deleted in the new process.

Please let me know what you think about this.

MudGuard · Post by **MudGuard** » Sat Jul 23, 2005 9:54 am

just a suggestion:

c) Option b) in combination with a new command line option --save_these_settings (or something similar)

Only if the additional parameter is set, the settings would be written to the registry (or wherever they are stored)

Post by **psguru** » Sat Jul 23, 2005 11:36 am

I think what I proposed is more intuitive: the current behavior will be the same (command line options are not saved unless the user goes to the Options dialog and hits OK), and the problem with not using command line options in spawned comparison will be transparently fixed. Adding yet another command line switch is something I'd rather not do.

j_hoppe · Post by **j_hoppe** » Mon Jul 25, 2005 2:29 am

Hello psguru,

I think your solution ("generate an temporary option file with the effective options
of the first EDpro instance and call the second instance with /g") should do it.

As a minor enhancement, I would not use the "/g"-option in this case but use another new option identifier, which
is only internally documented (something like "/g_spawn"). This gives you more flexibility, if in
future versions of EDpro more/other information must be transferred to the spawned instance.

Can you give me a pre-release, if you implemented any solution?

Thanks,

Post by **psguru** » Mon Jul 25, 2005 4:52 am

As a minor enhancement, I would not use the "/g"-option in this case but use another new option identifier, which
is only internally documented (something like "/g_spawn"). This gives you more flexibility, if in
future versions of EDpro more/other information must be transferred to the spawned instance.

I think /g is sufficient. The intent is to capture all EDPro options in the Options file, for all existing and future settings.

Can you give me a pre-release, if you implemented any solution?

Yes, I'll let you know when the preview is available. I expect it to be a couple more weeks.