BorlandTalk.com

server · Guest

message unavailable

Jens Gruschel · Guest

Mike Martin · Guest

You need to use the delphi command line compiler. I believe it's dcc32.exe
in Delphi 3, 4 & 5. Run it from the command prompt, and it will tell you
everything you need to know.

Of course you will also need use ShellExecute() to launch a program from
within your program.

Uses
Shellapi;

Then, this should cause notepad to start and open a file.

procedure TForm1.Test2Click(Sender: TObject);
begin
ShellExecute(handle,'open','notepad.exe','mynotes.txt','',sw_SHOWNORMAL)
end;

The snag with this, is that the ShellExecute routine does not stop your
program. The program carries on without waiting for the child app to finish.

"Venkatesh VT" <venks (AT) vsnl (DOT) com> wrote in message
news:433200d9$1 (AT) newsgroups (DOT) borland.com...

Darren · Guest

This happens when the Form's position is set to poScreenCenter. Not sure
why.

Enquiring Mind · Guest

Hi,

Please see the post in the borland.delphi.com.activex.writing newsgroup
that's hyperlinked below. It relates to deployment issues:

news:45ba1c11 (AT) newsgroups (DOT) borland.com...

Regards,

Enquiring Mind

Enquiring Mind · Guest

Hi,

It seems that knowledge about deploying DCOM applications in a network is
rather thin on the ground, judging from the lack of response from the
newsgroups! Maybe Dan Miser had a point when he wrote in the chapter on
developing MIDAS applications in Delphi 5 Developr's Guide that DCOM
configuration is something of a black art. I appreciate that it's primarily
an operating system issue, but given that Datasnap offers DCOM as one of the
transport options, I would expect to see more support on this issue in the
Delphi documentation.

After some research I concluded that relying on DCOM perform caller
authentication and authorization in a Workgroup network is fundamentally
flawed, because of the lack of a central directory of network users against
which to authenticate the caller. Then again, if as a work-around user
accounts are duplicated on client and server machines, they will be
difficult to keep synchronised. So I decided to disable operating system
level security for the server application. To this end I set
'Authentication Level' to 'None', and included 'Anonymous Logon' and
'Everyone' in the the list of users authorized to Launch and Access the
server. I also added exceptions to the firewalls running on the client and
server computers to allow DCOM to pass through and connect to the software
module on the respective computer.

Having made these security settings for the server application, lo and
behold the DCOM server actually gets launched when the client program is
launched on another computer in the Workgroup LAN! However the error message
'Access is denied' still shows up on the client. This seems to suggest that
the settings have worked as far as launch permissions are concerned, but not
as far as the access permissions; or perhaps that the return journey from
server to client is being blocked.

I have read in Binh Ly's techvanguards.com website that when he tried to
set up the permissions for the server, the settings only worked when applied
to the computer, but not when applied to the specific server application. In
my case I have applied the settings to the specific application, being
reluctant to compromise the security of the other DCOM servers on the
computer. Does anyone know whether Binh Ly's observation that security
settings applied solely to the server application don't work still applies?
Also to allow the DCOM modules to communicate over a LAN through firewalls,
is it sufficient to include port 135 in the firewall port exceptions, or
does DCOM dynamically generate other port numbers than may be blocked by the
firewalls?

Regards,

Enquiring Mind