Two apps that open each other 1

[MagicFrisbee]

I have the source code for two Win32 VCL applications. That means I've got class names, Captions, and install locations for both executables. A button in each program opens the other. If the other program is already open, it should show it (bring it to the front). If the other program is minimized, it should show the application how it was before being minimized. That means, I don't want to send a straight RESTORE message to it if it was maximimized before being minimized.

So, what's the code block look like for this? I've tried FindWindow to no avail, ShowWindow with aweful results, etc.

GIS Programmer
City of Orem, UT

http://gis.orem.org

 

[DelphiAaron]

1 way is to put a single instance component on the forms of the 2 apps, then if you call shellexecute the app will open if it doesnt exsist or restore if it does.

Aaron

 

[MagicFrisbee]

Except that the user can opt to have more than one instance of these programs and it's OK. Having the single-instance component would prevent this. Smart suggestion, though.

GIS Programmer
City of Orem, UT

http://gis.orem.org

 

[CamaroLT]

I'm confused at this point then. You have two separate applications that can launch each other. Ok, I get that and I can see some use for that. What I don't get is the whole max/min/restore deal? If the one app kicks up another and you don't want to check for single instance, whats the concern about the window state of the other applications?

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job

 

[MagicFrisbee]

Good question. Here is the practical situation. For simplicity, we'll just call the applications A & B.

User runs application A. She uses it to quickly open application B using a button in A. She minimizes B and continues working on A. Then she clicks the button in A again and instead of bringing up a new instance of B, it restores B and activates B's window.

Next, the user decides that she wants to have two instances of B up because she wants a side-by-side comparison of information. She is free to bring up application B using the normal means (meaning, instead of using A's button).

And what I've said about A could be said of B, and vice versa.

GIS Programmer
City of Orem, UT

http://gis.orem.org

 

[CamaroLT]

Ahhh.. So what you want to check is if the program B from program A, then restore that particular instance. But if the program is run, say from a shortcut on the desktop, not a problem.

Maybe setting up a client/server component with Indy might help. I can see why the single instance checker won't work.

Theory I've got is that if you setup one program to act as the server, have it create a TCP socket server on any random port. Use TRY/EXCEPT to make sure you're not stepping on anyone elses toes. When starting the call to run App B, add a command line parameter to tell the software to connect to App A's port.

Once the connection between the two applications is made, when the user wants to re-open the second application, a check is done to see if the program A has already launched it. If so, send a simple command over the TCP connection, and have the client automatically restore itself. In application B, if its got to open up Application A, you can check to see if there already is a connection to A. If not, make a new server, then launch A.

It'd make quite the web of applications. I would almost say it might be a better idea to take these two applications and throw them into an MDI application instead of having a whole bunch of SDI's kick'n around.

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job

 

[roo0047]

Wouldn't a simple solution be to use an INI file?

* At A startup, look to see if B is running, or another instance of A and respond as required. Clear any old INI flags if not.

* If B is launched from A, read the INI, write to event flag to INI.

* When B is closed, Have it clear its own flag in A's INI.

All of your logic code would be determined by the contents of the INI file.

Abstract, but you should get the idea...

(Note: You'd have to close the INI after every read/write for the 2 apps to share the INI.)


Roo
Delphi Rules!

 

[CamaroLT]

Good suggestion but I see cons than pros with the INI option. To be fair, and not to sound like I'm attacking your suggestion, this is what I see as pros and cons for both the INI option and Socket options. I fully endorse your suggestions to this list.

Pros and cons of INI files:
Cons:
Many applications wanting to get a hold of one resource isn't a great idea. Even in the database world, theres only ONE object that has hold of a row in a table. Many objects may want to take hold of that information contained with in a field of that row, but they have to talk through the governing DB connection object to obtain that information.
Many applications starting and stopping moves PIDs around, not necessarily chronologically speaking. PIDs get reused, and there are possibilities that issues will arise due to this fact.
No direct method of communication between parent and client. Part of the rule set is that the parent needs to give the child new information.
Timers to babysit things are ugly.
Nightmare to try and figure out what processes are PID 445, 4435, 6547, 9547 and who belongs to what process.
Definitely not OOP type of programming.
If programs crash, stale data ends up in the INI.

Pros
Small file foot print.
Not a lot of resources consumed outside of disk activity, which is low due to windows caching of files.
Something tangible to look at.

Pros and cons of TCP Socket

Cons:
In the spirit of timers, consumes memory and resources such as network stack and memory addressing. But this use is for real time data exchange.
It is easier to play with INI files to an extent rather than sockets if you're not confident on how they can work.

Pros:
Direct, live information feed from parent to client.
No outside interference in communications. Commands from the parent can be sent to the child process, and confirmation via handshaking or the disconnection event will confirm if command has been sent.
Event driven for information received through the socket. IE: Disconnections, connections, commands.
More along the lines of OOP. Its one on one communication between parent and child.

--

Relying on PIDs and memory addressing isn't the best of ideas, especially when it comes down to looking at where something is placed when your application does NOT have control over it once its launched. Its kind of like giving your kid your Suburban, which may have GPS and a call-home feature that monitors speed, but doesn't mean you can control what the vehicle is doing.

Another pro to a socket is that since he has the source code, a the client TCP socket can receive commands and issue the proper procedures to get whats needed to be done, done. That is assuming of course the source is written properly.

For instance, if a file has to be loaded in the child, the client may have in the GUI a FILE> OPEN> and a dialog to let the user select the file, but if the parent already knows what it is, at the click of the appropriate button, the parent can feed the OPEN command directly to the client via a custom text based protocol (For example OPEN:c:\dork.txt), the client receives that by method of an event, and then realizes its supposed to open a file. So it sets a the filename variable, calls the procedures to load and display the data, make sure its visible and on screen and in a RESTORED state. If the server say something like TAB:3 the server can tell the client to switch to the third tab, so on and so on.


-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job

 

[MagicFrisbee]

These are all valuable posts, but should the solutuion be simpler than that? All I need is for one program to find the running instance of the other. And if it finds it, I would think just one to three Windows API calls should open the window, restore it, or bring it to front, since I know the program's main form class name and caption. If the program isn't running, this is a simple solution since I then simply execute it. But no, I don't need to pass information between the programs.

GIS Programmer
City of Orem, UT

http://gis.orem.org

 

[whosrdaddy]

Agreed MagicFrisbee,

As I understand you can retrieve the handle of the other app using FindWindow?

if that is the case you can use a simple postmessage and a user defined message.

Psuedo code (untested)

// APP A
uses Messages,...
...
  const
   WM_USER1 = WM_USER+1;
  type
    TFormA = class(TForm)
    ...
    private  
    ...
      procedure wmMessageFromOtherApp(Var Msg : TMessage); message WM_USER1; 
    end;

....
procedure TFormA.wmMessageFromOtherApp(Var Msg : TMessage);
begin
 // put here your restore code
 // this is a neat trick to bring an app into front
 // without the need to check for minimized, etc...
 Application.Minimize;
 Application.Restore;
end;

// APP B
progam APPB;

var Handle : THandle;

begin
 Handle :=FindWindow(Pchar('ClassOfAppA'), PChar('CaptionOfAppA')); 
 if Handle <> 0 then
  PostMessage(Handle, WM_USER+1,0,0)
 else
  // start APP A
  ShellExecute(APP A with params....);
 Application.Initialize;
 ...
 Application.Run;
end;

this code only show APP B checking APP A, you need to mirror the code for APP A that checks APP B.

I hope you understand this a bit...

Cheers,
Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[CamaroLT]

So long you can assign unique caption to the name, ok, I ceed the whole sockets ordeal. If however you don't have uniqueness theres going to be issues.

-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job