Hi,
A problem, a hack to solve it, and a suggestion for a better solution: I've been having difficulty making a deployed console app that uses simple TCP/IP streams. The app just sends some data to a server, waits for the response, and prints it out. I have a GUI version of the app that works pretty-much OK, but the console version failed to open the socket -- or rather it failed to create WinAsynchSocket>>default as part of SocketAbstract>>allowAsyncEvents called from #connect. My first thought was that it needed the "normal" windows event loop running (as Blair has said in the past), so I did a #forkMainIfMain, but that didn't help. So I also explicitly sent #onStartup to WinAsynchSocket as part of my startup (before #forkMainIfMain), but that didn't help either. I still have no idea how to do asynch processing on a socket in a command-line app, but I realised I didn't need it for this application, so I tried a different tack. There's no easy way of turning off the call to SocketAbstract>>allowAsyncEvents as the socket is connected (especially as the part of my code that handles the socket stuff doesn't know it's in a deployed app at all, let alone that it's a console app) so I hacked it. I just put: "turn off ability to do asynch socket ops" SocketAbstract basicCompile: 'allowAsyncEvents' into the #preStripScript for the image stripper. That's a shocking hack, I'll admit, but it does work. It removes the attempt to allow asynch ops on any socket in that deployed application. So my little app now works fine. However there should be a less hacky way of making sockets aware of their context. I suggest doing a double-dispatch during Socket connection, something like having the socket send: SessionManager current onSocketConnected: self. which would be implemented (by default) to send back #allowAsyncEvents by GUISessionManagers and be ignored by ConsoleSessionManagers. BTW, does anyone know how to allow asynch processing in a Console app ? As I said I, couldn't get it to work, but even if I had been able to initialise a WinAsynchSocket properly, it seems to be using DesktopView>>current which sounds dodgy for an application that might be invoked via Telnet for instance. -- chris |
Chris,
> A problem, a hack to solve it, and a suggestion for a better solution: > > I've been having difficulty making a deployed console app that uses simple > TCP/IP streams. <lots of hacky stuff snipped> Just for your info, we have added another Sockets library to D6 (the old one is still present though) that makes use of overlapped calls and dispenses with all of the asynchronous window nonsense. Best Regards, Andy Bower Dolphin Support http://www.object-arts.com --- Are you trying too hard? http://www.object-arts.com/Relax.htm --- |
Andy,
> Just for your info, we have added another Sockets library to D6 (the > old one is still present though) that makes use of overlapped calls > and dispenses with all of the asynchronous window nonsense. Yea! <salivates> -- chris |
In reply to this post by Andy Bower
"Andy Bower" <[hidden email]> wrote in message
news:3ee62bd2$[hidden email]... > Chris, > > > A problem, a hack to solve it, and a suggestion for a better solution: > > > > I've been having difficulty making a deployed console app that uses simple > > TCP/IP streams. > > <lots of hacky stuff snipped> > > Just for your info, we have added another Sockets library to D6 (the old one > is still present though) that makes use of overlapped calls and dispenses > with all of the asynchronous window nonsense. I should just add that Dolphin console apps are true console applications in the sense that they are marked as such as far as Windows is concerned - yes for some inexplicable reason Windows differentiates between GUI and Console applications. Since .exe's are explicitly marked as one thing or the other, it is quite likely that a lot of GUI stuff won't work properly in console applications. As Dolphin's current socket library is based on the asynchronous sockets that use hidden windows to implement the notification mechanism, it may well be that they will not work in a console application. Of course you can always build a GUI application that to all intents and purposes appears to be a console application by (a) not opening any windows, and (b) using the standard I/O streams, which a Dolphin GUI application can also do. SessionManager current stdout nextPutAll: 'Hmmm, I didn''t know it could do that'; cr; flush Regards Blair |
"Blair McGlashan" <[hidden email]> wrote in message
news:bc7oks$fagb2$[hidden email]... > for some inexplicable reason Windows differentiates between GUI and Console > applications. I've experimented with this distinction a bit, and as far as I can tell the main difference is how the console input/output functions work. A console application always launches with a console (what we used to call a "DOS box") attached. If you launch it from the explorer, Windows creates a new console for it. If you launch it from a command line in an existing console, the application uses that console, and the console won't present the next command prompt until the program exits. A GUI application won't have a console unless it creates one explicitly. If you launch it from a command line, the console presents the next command prompt immediately, allowing the program to run independently. Both console and GUI applications can create windows and have GUIs and event loops and all that. GUI apps cannot use console I/O functions unless they create a console explicitly. And GUI apps cannot do I/O using the standard input and output handles unless you redirect them. It's easy to change a .exe file from a console app to a GUI app or vice versa, using a utility such as EDITBIN which comes with Visual C++. > Since .exe's are explicitly marked as one thing or the other, it is quite > likely that a lot of GUI stuff won't work properly in console applications. This hasn't been a problem in my experience. (My experience with this involves languages other than Dolphin ST though, so I'm only speaking of the basic Windows characteristics.) > Of course you can always build a GUI application that to all intents and > purposes appears to be a console application by (a) not opening any windows, > and (b) using the standard I/O streams, which a Dolphin GUI application can > also do. But then your application won't have a console attached when it runs. If you try to use the standard I/O streams, Windows will report an error, unless you've redirected them. (But again, I don't know how this works in Dolphin specifically.) |
"Harry Chomsky" <[hidden email]> wrote in message
news:[hidden email]... > "Blair McGlashan" <[hidden email]> wrote in message > news:bc7oks$fagb2$[hidden email]... >.... > > Of course you can always build a GUI application that to all intents and > > purposes appears to be a console application by (a) not opening any > windows, > > and (b) using the standard I/O streams, which a Dolphin GUI application > can > > also do. > > But then your application won't have a console attached when it runs. If > you try to use the standard I/O streams, Windows will report an error, > unless you've redirected them. (But again, I don't know how this works in > Dolphin specifically.) Dolphin will automatically open a console, hence my statement that Dolphin GUI apps can also use standard I/O streams, and the inclusion of an expression to evaluate in a workspace to demonstrates this. Regards Blair |
"Blair McGlashan" <[hidden email]> wrote in message
news:bc9bg0$gn5fa$[hidden email]... > Dolphin will automatically open a console, hence my statement that Dolphin > GUI apps can also use standard I/O streams, and the inclusion of an > expression to evaluate in a workspace to demonstrates this. OK, that makes sense. Then I guess the only difference you'd see between this kind of application and a "real" console application is the behavior if you run them from a command prompt. The Dolphin GUI app will open a new console, allowing the original console to display its next command prompt immediately. The "real" console app will use the existing console and delay the next prompt until the program exits. |
Free forum by Nabble | Edit this page |