[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Capture output to separate window
Capture output to separate window

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Posted by Nikkei   Singapore  (8 posts)  [Biography] bio
Date Tue 23 Jan 2007 02:27 AM (UTC)
Message
Certain muds have huge amount of output. Currently, selected outputs can only be sent to notepad. Is there anyway to allow selected outputs to be sent to a separate(movable) client window, with color and all?
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #1 on Tue 23 Jan 2007 05:05 PM (UTC)
Message
Umm. Sort of. There is a way to create a new world window, which isn't connected to anything, then use that for output. There is also the possibility, if Nick ever gets it to work, of "building" such a window, using wxLua, instead of Lua. We discussed this a bit before, but got caught up on some threading issue that I am not sure is even relevant, since the whole point of "event driven" applications is to *prevent* threading issues...

At the moment though, the only options are a new world window, which has its own issues, or a notepad. Don't have time to find the thread on using a new world window at the moment, so someone else will have to point you that direction.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #2 on Tue 23 Jan 2007 05:27 PM (UTC)
Message
Quote:
since the whole point of "event driven" applications is to *prevent* threading issues...
Methinks you should read up on e.g. the Swing architecture docs... Swing is event driven and yet relies very heavily on threads. If you do your processing in your event thread, you're in for trouble. Any kind of blocking in the event handler is bad times.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Tue 23 Jan 2007 06:42 PM (UTC)
Message
Quote:

Is there anyway to allow selected outputs to be sent to a separate(movable) client window, with color and all?


This is a double posting, which I responded to in:

http://www.gammon.com.au/forum/?id=7615&page=999

I would appreciate it if questions were posted once, to save time and effort.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #4 on Tue 23 Jan 2007 11:46 PM (UTC)
Message
Hmm. Well David. In this case the critical issue is causing the client to pause and there "does" exist means to create alternate threads for things that take long term processing. Coprocess, co-something or other.. don't remember exactly, since I wasn't looking for a Lua solution at the time for this, but something more universal. Turned out, when dealing with the GUI API there is no such thing as a "universal" solution, unless you want to build it yourself. :(
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #5 on Wed 24 Jan 2007 12:12 AM (UTC)
Message
Right -- the common solution is to create a separate thread that does the computation and at some later point synchronizes with the GUI thread which then updates whatever needs to be updated (e.g. a textbox after making an HTTP query).

However that requires several things:


  • most obviously your language needs proper threading. Lua's coroutines are not sufficient for this purpose, as they are blocking -- they are not proper multi-threading.

  • your thread, once you have it, needs to be able to plug into the event handler thread -- most of the time, the event handler thread is the main application thread. (E.g., you start up the program and do something like while(running) { process events }

  • in our context, all of this is happening in the scripting environment. That means that the scripting environment itself needs to be able to communicate with the event handler one way or another.



For that last bullet point to really work would require two main things:


  • a fundamental rewrite of the MUSHclient event handling so that it can take messages from scripting engines and handle them in some reasonable way. This entails all kinds of interesting synchronization problems.

  • all scripting environments that want to communicate with the main event handler need some way of doing it.



My point is that it's not a simple matter of plug-and-playing the code somewhere or flipping a flag or some short job like that. I'm not saying you were suggesting that it would be easy, I'm merely trying to point out that it really is not a trivial problem at all. (And, I'm also trying to explain why the threading problem is in fact extremely relevant.)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #6 on Wed 24 Jan 2007 05:17 PM (UTC)
Message
Umm. I am not sure that the script can't fire events for itself to handle. LuaCOM provides event handling if you are using Lua, while wxLua provides that functionality as well, it has to, since its a GUI extention. As for coroutines... I was under the impression that Nick got them to work *without* blocking the client.

In any case, how much processing do you need to do here, for like 90% of the stuff you need to handle? Sure, some things "might" present issues, but worst issue might be needing to either a) make an external application to handle the heavy work, or b) Nick working out some way to run scripting in a thread that isn't the same as the main client. Again, how much "processing" does it take to create a window, position it, add some sort of Richtext box, then feed that window data? No more in this case than the amount you are "already" doing to feed the lines of text to a different world window. I can think of very few cases where the processing is so heavy that it would be any worse using wxLua than it is "already" using what we already have.

Oh, and I think you are as confused as I was about how events work. An event generating object has a function called "connect", this works basically like:

connect myobject.myevent, location("my function")

Mushclient ***doesn't*** need to have any way to recieve events from the objects created. The only requirement is that you *tell* the object what the current "location" of the script function is in the script space, so it knows the entry point to call when the event takes place. Mushclient doesn't even know it happened, but it works anyway, because the script function is called "directly" when the event fires. Events "generated" by a script engine, as unlikely as that is, would also be directed to the script function "in" the script engine, not to Mushclient. Only callbacks to Mushclient need ever be used to infor it of anything taking place in the script system. So, unless you are a complete nitwit and design your script with a non-terminating loop or *huge* time wasting loops, adding GUI elements and events won't effect things any more than any existing non-terminating loops or huge time wasting ones already do. Its a non-issue.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #7 on Wed 24 Jan 2007 06:15 PM (UTC)
Message
It all depends on whether or not threads are running in the first place to manage these event handlers. In LuaCOM, for example, I don't know how the event model is set up. Maybe it handles events sent to it, but how do those events get there in the first place?
As for wxLua, it probably expects itself to be the main event handler anyhow.

Quote:
As for coroutines... I was under the impression that Nick got them to work *without* blocking the client.
Yes... except that as I said, coroutines are not proper multithreading. There is no parallel execution going on. So the client isn't blocked, but the coroutine isn't doing anything as long as the client is! (and vice-versa)

Quote:
Oh, and I think you are as confused as I was about how events work
Well, ok, except that I've actually programmed this stuff in C++ before and have written GUI applications that interact with sub-windows managed by libraries (OpenInventor, in one case, which is a 3d drawing library) and so forth. :-)


Anyhow, as I said previously, my point is that it's really not that simple.
I would suggest, perhaps, that you throw together a skeleton application in e.g. C++ that hosts a scripting environment that creates its own windows using wxLua, while the host application continues doing whatever it is doing. That way we all could learn something and Nick would have a concrete example to work from. Or, we could pinpoint more precisely the differences involved that prevent it from being so simple.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #8 on Thu 25 Jan 2007 05:09 PM (UTC)
Message
Quote:
It all depends on whether or not threads are running in the first place to manage these event handlers. In LuaCOM, for example, I don't know how the event model is set up. Maybe it handles events sent to it, but how do those events get there in the first place?


Sigh.. Ok, the thing it, event handlers don't *quite* work as I, and apparently you, thought. LuaCOM's "connect" function basically contains code like:

obj.idispatch("CONNECT","Source","Destination")

This is *roughly* what goes on on the most base level. Now.. As to how it gets there... If I create a window in wxLua, I have to give it a parent. This can be the system itself, "NULL", or another window. If I give it another window, then the *system* should handle it like this:

Fire_Event-> (click, mybutton on my_window)
System-> Pass event to Mushclient main window.
Mushclient -> Does this belong to the main window? No, return it to the system.
System -> Send it to first child of Mushclient main.
And so on...

Technically, as I understand it, unless the main application is doing something it shouldn't, like trapping and throwing out all events it doesn't recognize as its own, it should eventually get passed on to the new window, and thus to that windows own objects. This is why its in fact possible to do things like hiding or closing other applications windows, also using system wide "events", targetted at those windows. No special processing should be needed. Mind you, I *may* be wrong about that, which is why I am going to drop a note over to a forum on the subject of wxlua or wxwidgets, to see if I am right. But frankly, the amount of change to the code likely needed at all would be minimal, especially given than the automation code should "already" be in Mushclient to handle things like vbscript.
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #9 on Thu 25 Jan 2007 05:25 PM (UTC)
Message
Quote:
LuaCOM's "connect" function basically contains code like:

obj.idispatch("CONNECT","Source","Destination")
I honestly don't see what point you are trying to make with this line of code. OK, great, you have an object upon which you call a method with a bunch of parameters. That says very little (well, nothing, really) about the underlying event model or threading system.

In any case if I understand you correctly, you are suggesting that currently the only obstacle to having e.g. wxLua completely work under MUSHclient is that MUSHclient is trapping messages that are for its subwindows... is that what you are saying? What about all the threading issues?

Don't forget that all this wxLua code is running inside the thread engine which is running inside of the MUSHclient application. How the threading is set up in all of that is critical as to whether or not all this will work.

I still think that having an example program would clear this up immensely; something small that demonstrates how to embed a scripting engine into a host app, and have the scripting engine create interactive windows and so forth.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #10 on Fri 26 Jan 2007 02:36 AM (UTC)
Message
Yeah. I think an example would clear it up. I know about as much about C++ though as an auto mechanic does about space shuttles though.

But no, what I am saying is that, in theory, Mushclient shouldn't "ever" trap an event that its not specifically aware of. In fact, if a main event loop "does" trap such events and throws them out, it could accidentally throw out system events, video driver events, file system events, and of course *as yet unhandled* events for other applications. A correctly written event procedure looks for only those events *specifically needed for that application*, then hands any event it doesn't recognize back to the OS, which then passes that on to the next process in its list. While dlls, including Lua and wxLua exist in the same thread as the client they run in, its not entirely clear if they, or their objects, *actually* exist as recognizable processes in the main OS, which would mean that they would recieve their *own* events.

As for an example. They provide several, some of which include C++ applications that *run* the scripts in them. I am not sure any use their own window, then glue on the wxlua system though, which is why I plan to spend some time hunting the forums and hoping I get a sane answer. Unfortunately, often the answers come from people that either don't understand what you are asking, because they think you are using it just like the existing examples, or just think you are a moron for not "knowing" what they hell you are doing to start with. Here's hoping... lol
[Go to top] top
Posted by Nick Gammon   Australia  (22,975 posts)  [Biography] bio   Forum Administrator
Date Reply #11 on Fri 26 Jan 2007 03:43 AM (UTC)
Message
Quote:

Mushclient shouldn't "ever" trap an event that its not specifically aware of. In fact, if a main event loop "does" trap such events and throws them out, it could accidentally throw out system events, video driver events, ...


The first point to make here is that MUSHclient is written using MFC (Microsoft's libraries) and, as such, does not directly receive events in the first place. Incoming events are processed in the bowels of MFC - and I use the word advisedly - and MFC decides which events to pass to my functions, which to handle itself, and which to send to the operating system for default management.

The strong likelihood is that events intended for other windows (eg. wxLua controls) would seem, to MFC, to be irrelevant, and thus would be thrown away, or given default treatment. I can't see how they would somehow cause the script engine to be started and a certain function inside it, called.

Quote:

While dlls, including Lua and wxLua exist in the same thread as the client they run in, its not entirely clear if they, or their objects, *actually* exist as recognizable processes in the main OS, which would mean that they would recieve their *own* events.


I think you are confusing here DLLs - which are effectively "included object" - with threads or processes.

A DLL is really just some functions that are shared between processes, and by using them, you save having identical code in memory lots of times. But by using a DLL you are not, per se, starting a new thread, or a new process.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #12 on Fri 26 Jan 2007 03:32 PM (UTC)
Message
Well, that depends on the dll. And I don't mean it would start a new thread. Individual windows don't have their own threads either, but they *do* have unique IDs in the OS, which the system can use to do things like searching for them or hiding all of them to display the desktop, etc. All such messages are basically events. If it was possible for the system to be unable to hide/close a window, then it would make sense to argue that threading is some huge issue. And yes, that does happen, but usually only in rare cases where the application thread is hung up in some sort of loop of its own, and isn't even able to recieve its "own" events, never mind system generated ones. I.e., the application has to completely stop responding to everything for that to occur.

It is a valid question to wonder about, but imho, if the system knows the window/object exists, then it should be possible for it to fire/recieve events. I could be wrong, which is why I posted a question about it yesterday on another forum.
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

32,632 views.

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]