1

I've made a chat server using ScktComp and Winsock in a Windows form. How can I make the same thing in an console application?

I found this as a starting point but, the links inside (which the thread's author replied "almost perfect answer") are expired.

What's the equivalent of ServerSocketClientConnect / ClientSocketConnect and the other methods inside in a console app?

onkar
  • 4,427
  • 10
  • 52
  • 89
Eduard
  • 3,395
  • 8
  • 37
  • 62
  • This is very broad. What particular aspect is bothering you? – David Heffernan Jan 03 '13 at 14:01
  • The links on that page are only bad because the site's forum software changed its URL structure sometime between March 2002 and today. The relevant posts are still there: [Whats wrong with this code? by b-w-d.net](http://www.delphipages.com/forum/showthread.php?t=37770) and [the search page](http://www.delphipages.com/forum/search.php) with search phrase `^gLes TMyEvents` (i.e., posts from user gLes about TMyEvents). – Rob Kennedy Jan 03 '13 at 15:14

2 Answers2

3

Delphi uses the same classes and non-visual components in console applications. You don't need to change what classes you use, but you do need to learn how to add things to units by typing them out manually instead of relying on the Delphi IDE to generate the code for you.

You could create them yourself by using the steps below, or you could use a data-module already constructed while using a VCL Win32 GUI application containing non-visual components, within a console application.

Steps:

  1. Add unit name that contains the class or component you want to use to the Uses clause.

  2. Construct the component as if it were a class:

      var
    aSomething:TSomething;
  begin
    aSomething := TSomething.Create(Parameter1,Parameter2);
  end;

  3. Remember to free it at the right place.

         aSomething.Free;

However I have a hard time understanding why you would want to turn a chat server into a console application, other than as a toy, or an experiment. In real world use, you probably want a Win32 GUI, or else you want a completely non-visual service (an NT-style Service), which you can create, without changing the APPTYPE to console, but which could run without any GUI, nevertheless.

The primary practical reason I can see for writing console applications is to write things which are useful from the command-line, such as build helper utilities, etc. Making a console application is in and of itself extremely easy. Start by creating a new empty console application, add a new empty pascal unit to it, make a main method, then add the unit names you want to the uses clause of the main-unit you are working on. That's all there is to it.

You could keep using the server socket and client sockets you're currently using, although I would like to suggest you forget about the console app, unless you really need it, as all you're doing is making development and operation of your program more difficult for no real purpose. You don't have to change components or classes to use them in a console application, however, I should say that GUI or console alike, that the TTcpClient and TTcpServer components on the "Internet" tab in Delphi are not suitable for real use in any real world application. They are there for backwards compatibility and should be considered "out of date" and "no longer to be used in any serious way".

Look at a real TCP/IP library like Indy, ICS, Synapse, or anything, anything at all, other than those components from the "Internet" page of the component palette, which are not suitable for real world use in any scale other than "toys".

Warren P
  • 65,725
  • 40
  • 181
  • 316
  • If you are interested in Windows specific console TCP/IP demoes, ICS had a nice set and framework for it a few years go. Note that it might be more complicated then that since you might need to create a message pump. The ICS TApplication derivative does that for you (unit conapp was it called IIRC). Worth checking out even if you use a different socket suite – Marco van de Voort Jan 03 '13 at 14:54
  • Thanks for the advice, it's the starting idea I was looking for. – Eduard Jan 03 '13 at 17:27
-1

Some VCL classes need a Windows message loop and/or a window handle. So if you change the application type, they can stop working.

Also check if the existing code uses synchronize to run code in the VCL main thread. Using synchronize in a non-VCL application can be dangerous.

Community
  • 1
  • 1
mjn
  • 36,362
  • 28
  • 176
  • 378
  • Do you know if INDY works fine in console apps? I know TTimer requires a message handle, but you can still have a Win32 message handle in a CONSOLE app, right? You just can't create VISIBLE windows. I'm pretty sure that just because the AppType is CONSOLE that doesn't block calls to CreateWindow. :-) – Warren P Jan 03 '13 at 19:57
  • @WarrenP yes, I use Indy TCP clients in console applications, or services. In general, there is no need for windows handles as long as no asynchronous Winsock API methods are used. – mjn Jan 08 '13 at 08:36