Firework Gadget

Posted by Shadowfyr on Wed 12 Nov 2003 02:58 AM — 20 posts, 76,758 views.

Shadowfyr USA Wed 12 Nov 2003 02:58 AM #0

Magnum has finally posted a gadget I designed to generate a fireworks display. This was a test project to let me see if it was possible to make a custom external program "Dock" with Mushclient, so that it resizes and moves in response to Muschlient's own changes. This means it should remain pinned to the side of Mushclient, so long as it still has enough room to fit itself in between Mushclient and the edge of your screen.

First the bad news:

This is probably best considered to be a Beta version, since there appears to be some issues with Mushclient failing to release the component if you use the Reinstall option for plugins and Magnum has reported some odd quirks with it under XP. I have no idea if his problem is due to XP, something I completely messed up or just the gadget reacting badly to the way he has Musclient set up.

Basically, as long as you have at least 50 pixels of space to the right of the Mushclient window it 'should' work. Same if you change the very basic plugin provide to use Top, Bottom or Left. There 'may' be problems for windows that lack enough space and I haven't yet made 100% sure that the code for anything except Right (and maybe Bottom) work.

If I can figure out how... I may also add the ability to have it always appear on top. This isn't an easy thing to do in VB6.

The good news:

It will work correctly, if your setup leaves space for the the gadget window on the right side of the desktop. It will correctly resize itself if you change the size of Mushclient.

If all else fails you can use the commands to "undock" the window, then manually "MoveTo" and "Resize" it to anyplace you like. It is still a good idea to let it "Dock" first, so that when it first appears, it won't grab the keyboard away from Mushclient.

Finally, this is designed to be a universal gadget. This means that 'any' client or program that can use ActiveX can give the gadget the name of that client's window (or usually part of it) and have it dock to that window the same way it does be default with Mushclient.

---

The plugin supplied with it is designed to do the bare minimum.

1. Connect to the gadget
2. Have it dock with Muschlient and
3. Provide a trigger and some code for the Ages of Despair mud that responds to a firework like event sometimes seen on that mud.

Instruction on how all the commands work is in the readme that gets installed with the gadget. ;)

You can get the gadget and basic plugin from:

http://www.magma.ca/~magnumsw/muds/mc_firework.zip

There is also an example program (with source) that shows the basic API functions needed to retrieve information about a window and which I used to get the info I needed to dock the gadget with Mushclient and to return control to it after. It doesn't have any of the complete docking code, but then I'm not going to do all the work for you. ;) lol You can get that example program and code here:

http://www.magma.ca/~magnumsw/muds/enumwin.zip

Hopefully I can find/fix any odd bugs I missed over the next few days or so. Best to hope I don't get distracted like Magnum did for the 4-5 days it took 'him' to even post these things. lol

David Haley USA Wed 12 Nov 2003 03:12 AM #1

It's actually quite trivial to make windows always on top. I've done it many times in the past...

[code]
Public Declare Function SetWindowPos Lib "user32" (ByVal hwnd As Long, ByVal hWndInsertAfter As Long, ByVal X As Long, ByVal Y As Long, ByVal cx As Long, ByVal cy As Long, ByVal wFlags As Long) As Long
Public Const SWP_NOSIZE = &H1
Public Const SWP_NOMOVE = &H2
Public Const SWP_SHOWWINDOW = &H40

Public Const HWND_TOPMOST = -1
Public Const HWND_NOTOPMOST = -2
Public Const HWND_BOTTOM = 1

------------

SetWindowPos formInfo.hwnd, HWND_TOPMOST, _
0, _
0, _
0, 0, SWP_NOSIZE Or SWP_SHOWWINDOW
[/code]

Where formInfo is the form you're trying to put on top.

Shadowfyr USA Wed 12 Nov 2003 04:30 AM #2

If you consider being forced to use API calls because VB doesn't provide a direct way 'trivial'. lol MY trivial attempt at using GetWindowRect blew up because the examples I was looking at used VB.NET, which has 32-bit Integers, but in VB6 requires Long. When you start getting into stuff like SWP_NOSIZE, trying to find a useful explaination of what the heck those things do... Thanks for the hint though. I suspect some other things are working a tad incorrectly, so I need to doublecheck them first, before I start playing with other things. ;)

David Haley USA Wed 12 Nov 2003 04:38 AM #3

I believe the NOSIZE means that you can't resize the window, but I'm not sure of that.

The problem is that you *have* to have API calls to do certain things in Windows programming. There's just no way around it. How can you expect to do things in Windows without ever talking to it? :)

And yes, I consider calling only one API command pretty straightfoward, as opposed to having to call a whole bunch. :P

I found that example not long ago by just searching on Google. There were tons of examples and explanations. I don't have the link anymore (clever me) but I'd imagine it'd be easy to find. Probably just search for "visual basic always on top".

Nick Gammon Australia Forum Administrator Wed 12 Nov 2003 05:08 AM #4

A 32-bit integer and a long are synonymous as far as I am concerned.
I would quote "always on top" when searching Google.

eg. search for: visual basic "always on top"
NOSIZE means ignore the sizing information (ie. you are supplying 0,0 but you don't really want the window resized to zero size. Similary for NOMOVE.

Magnum Canada Wed 12 Nov 2003 10:20 AM #5

The URL's ShadowFyr provided work as of today, but if I ever change ISP's in the future, the direct URL's may become obsolete. If that is the case, try http://www.magnumsworld.com/muds/ since that URL redirects to the pages hosted with my ISP, whoever that ISP may be.

Shadowfyr, while attempting to try out your program, I was running MUSHclient in Full-Screen, with a single world opened, also maximized within MUSHclient. When I grabbed the title bar of the Fireworks program with the the mouse and moved it to the right side of my screen, that window then disappeared from visibility, although it was shown on the Windows task bar. I tried right-clicking the taskbar tag for the program, and choosing "Move", but that would still not make the window visible. As I said in an Email, I'm running XP pro.

As a user/player, what I would find ideal:

Don't have the Fireworks program active all the time, have the plugin launch it only when it's needed. It could remain open until manually closed after that, or could automatically self-close some time after the fireworks had stopped.

Have the window always on top so I could continue to mud while it's showing it's stuff. Have it remember it's last position on my screen, so if it relaunches in the future, it does so in the same place.

IMO, the docking should just be the default behavior when the program is first run, and it may have a docking 'feel' when the window is placed in close proximity to it's associated program. (As seen in other docking software, that 'docks' when it comes within 2-5 pixels, for example).

These are just suggestions as a 'dumb user' who doesn't know what's involved in making it work. From a novice programmers perspective, nice work so far! :)

PS: It took me a few days because I had not yet installed any HTML editing software on this computer, and you didn't provide me with the "Documentation" web pages; you asked me to build them myself. If you want them hosted faster (or want more detailed documentation), please supply the documentation webpages yourself, then it's only a simple matter of uploading your complete work, which I won't be as likely to procrastinate on. :)

Shadowfyr USA Wed 12 Nov 2003 08:03 PM #6

Taking the comments in order of arrival:

Nick, under VB.NET they apparently made the decision to change the sizes of variables. It is now:

Short = 16-bit
Integer = 32-bit
Long = 64-bit

Same thing for Real and Double, this creates some understandable problems when you attempt to use a VB.NET example to call an API in VB6.

----

As to your comment Ksilyan, with VB.NET they apparently realized how patently stupid it is that you have to use API calls to get basic information about your own windows. For instance, while you can get the external size of the window, there is also an internal 'client' area that you are forced in VB6 to use API calls to aquire. However, to correctly resize control on a form, you often 'need' this information. Why? Because the title and menu bars both take up space that is not part of the 'client' area and the size of these things on most version of windows is dependent on settings in the registry, and worse still, under XP you can tell it to change the size of these things for every bloody program running. This info is a property of the form itself in VB.NET, but 'should' have been such even in VB6 imho. 50% of my code involves API calls that are not documented anywhere in the so called Professional Edition of VB6 I am using.

And if you don't even know what API call you need to look for, you can go completely nuts trying to find anything useful with a search like "capture message from another application". Odds are very good that this simple and straight forward search with turn up 0 hits, forcing you to spend hours trying simpler or less straight foreward searches, most of which are going to return 2 pages you might need and 10,000 that are about everything from seminars to the application of captured messages to covert operations, not to mention the pages where the keywords are so hidden that you can't even figure out how the heck google found them. lol I prefer things that if I 'have' to use them are documented and provided by the language itself. For things like PNG libraries or other things not necessarilly found in the OS's own internals, I expect to go hunting, not when I am looking for 'basic' user interface commands.

----

Hmm. So I do have a bug in the docking code. With Mushclient in full screen it is 'supposed' to stay where it is, instead of resizing itself. This is probably what it is doing, but every time you dragged it some place, it also immediately gives Mushclient back the window focus, which in turn buries the gadget under Mushclient. Without an always on top setting, it can't stay on top and not also steal away your ability to type.

Making it dock when it gets within 2-5 pixels is problematic.. Two problems arise with this. The first problem is it was designed as a generic component, not one specific to Mushclient. If you don't give it a dock command initially, as in the plugin, it literally has no clue 'which' window to look for when trying to dock. The second issue is that I am not sure at the moment how to continually check if the gadget itself is being dragged around.

Most programs that lock onto other windows like that are components of the main program. I.E. they are 'child windows' of the main application and thus things like where they are and how they relate to other windows in that program tend to be a whole lot easier to keep track of. This is far from simple to solve.

Because of these issues, I am not sure when/if I am likely to do the 'dock when close' trick. However, this is on my list:

1. Better testing.

I plan to make a window with a box to enter the name of the control (I will use this code in other stuff later, so need to test it again in those cases), a combo box to select 'where' to dock it, a button to make it dock/undock and finally a textbox to recieve debug info from the program. (Basically a mimic of Mushclient's .Note command. This should let me drag the window all around to do the testing, without having to fight Mushclient back into its original shape and size. This is a nice advantage of the control, since it was designed to work with any program, I don't have to test it only with Mushclient.


2. Right click menu.
  a) About
  b) Always On Top
3. Put back the minimize button.
4. Minimize to system tray??? This will occure if you:
  a) Click the minimize button.
  b) There are no firework events for 1 minute.
  c) Minimize Mushclient.
5. Auto restore on a firework event.
6. Offset option, to allow you to adjust distance and
  general position to the window it dock to.
7. Make the Close button kill the program, not just close
  the form (more of a bug fix).
8. Use window events from Mushclient to decide when to
  Resize, Move, Minimize or Restore, instead of a timer.
9. Change things so that when minimized, the fireworks will
  still cycle down, but not attempt to draw.

Of these I am uncertain how to do any except 6, 7 and 9. lol

I also previously abandonned item 6 on the ground that it added addition complications I didn't want. It still may... I may instead make a Soft Dock option. So a normal dock will do what it does now and attempt to make the window as big as space allows. A soft dock would use the 'dock when close to the window' feature, but allow you to manually resize it. It may be better to ignore option 6 completely and let the soft dock simply slap itself against the window where ever it is, then you would move it up/down, left/right to 'fit' it in the right place when other controls are involved. Hmm.. then that brings up what to do if you shrink a window in both directions, instead of just the one related to the docking position.... Grrr.. This is going to be complicated..

Anyway.. I don't advise holding our breath expectantly for these changes. ;) lol

Shadowfyr USA Wed 12 Nov 2003 08:06 PM #7

HTML editing software?? A real coder does it by hand. lol

Yeah. I can understand that and didn't even think about that. Not that I wanted to do it either. ;) lol

Poromenos Greece Wed 12 Nov 2003 09:35 PM #8

There is a way to get the size of the working area in VB6, it's Form.ScaleWidth and Form.ScaleHeight, if that's what you mean...

Shadowfyr USA Wed 12 Nov 2003 09:43 PM #9

Uh... And that works how? lol Seriously, I saw mention of those things some place, but never a good explaination of what they heck they actually where or how they actually worked... The fact that you can change them and not change the form size doesn't help. The API call is simplier, much more straight forward and describes what it does. In VB.NET they apparently use Form.ClientArea.width or something like that. This makes a lot more sense and doesn't require a lot of wierd conversions, unfortunately is it only available in .NET, which won't run on any older systems. :(

Magnum Canada Thu 13 Nov 2003 02:26 PM #10

Ah, the lock-docking thing was merely a suggestion since you were attempting to dock in some manner anway. In truth, I don't actually care about such a feature.

I can't say I would be thrilled at having the fireworks program loaded all the time, to only be used on the rare occasion where fireworks launch in the mud. I would much prefer as I suggested before, launch the program when needed, and close it when not needed [via the plugin].

Besides those points, it's an interesting project you are working on, simply for the techniques you demonstrate. :)

Shadowfyr USA Thu 13 Nov 2003 04:47 PM #11

Yes. I am not 100% certain that continually calling the API calls for finding the window and reading it is entirely reliable, so I already made changes to my copy of the plugin to do exactly that. I had Mushclient crash on my system about 2 hours into using the gadget, I assume due to some unknown conflict involved with reading the window information for it from a completely different thread. It is possible this glitch only occures under 9x systems and only then after several thousand such calls. The gadget currently has no way of knowing if the window state changed besides reading it, so it uses FindWindow and GetWindowRect once every 100 milliseconds to verify that it is still where it was last. Hopefully I can find some more reliable and less wasteful way to manage that. Intercepting the windows Minimize, Restore and Resize system messages would be ideal, but most of the examples for this only show how to intercept your own programs messages. :p

I'll keep looking, but for now the altered plugin is:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE muclient>
<!-- Saved on Saturday, November 08, 2003, 9:13 PM -->
<!-- MuClient version 3.42 -->

<!-- Plugin "MC_Firework" generated by Plugin Wizard -->

<muclient>
<plugin
   name="MC_Firework"
   author="kagehi"
   id="d25cbd257faedacf03e497db"
   language="VBscript"
   purpose="Ages of Despair plugin that gives an example of using the MC_Firework control."
   save_state="y"
   date_written="2003-11-13 10:55:00"
   requires="3.42"
   version="1.1"
   >
<description trim="y">
<![CDATA[
This plugin provides an example of how to use the MC_Firework control.

It also generates some fireworks based off of the color names sometimes used on Ages of Despair, instead of the ansi colors.
]]>
</description>

</plugin>


<!--  Get our standard constants -->

<include name="constants.vbs"/>

<!--  Triggers  -->

<triggers>
  <trigger
   enabled="y"
   match="^Off in the distance\, a (.*?) ball of fire lights up the sky\.$"
   name="Firework"
   regexp="y"
   script="GenSpark"
   sequence="100"
   other_text_colour="black"
   other_back_colour="black"
  >
  </trigger>
</triggers>

<timers>
  <timer name="DockTimer" script="DockTimer" enabled="y" second="3" active_closed="y">

  </timer>
  <timer name="KillIt" script="KillIt" enabled="y" minute="2" active_closed="y">
  </timer>
</timers>

<aliases>
  <alias
    match="MC_Firework:MoveTo *,*"
    enabled="y"
    name="SetPos"
    script="SetPos">
  </alias>
  <alias
    match="MC_Firework:Size *,*"
    enabled="y"
    name="SetSize"
    script="SetSize">
  </alias>
</aliases>


<!--  Script  -->


<script>
<![CDATA[
dim hndl
dim Repos

sub OnPluginInstall
  set hndl = createobject("MC_Firework.MC_Spark")
  note "Firework plugin installed"
  enabletimer "DockTimer", 1
  Repos = "False"
end sub

sub DockTimer(name)
  hndl.dock
  hndl.createspark("red")
  hndl.createspark("green")
  hndl.createspark("yellow")
  enabletimer "DockTimer", 0
  enabletimer "KillIt",1
end sub

sub KillIt(name)
  set hndl = nothing
  enabletimer "KillIt",0
end sub

sub GenSpark (name, output, wilds)
  enabletimer "KillIt",1
  resettimer "KillIt"
  if typename(hndl) <> "MC_Spark" then
    set hndl = createobject("MC_Firework.MC_Spark")
    hndl.dock
    if Repos = "True" then
      hndl.undock
      hndl.MoveTo getvariable("PosX"), getvariable("PosY")
      if Cint(getvariable("Width")) > 49 then
        hndl.Resize getvariable("Width"), getvariable("Height")
      end if
    end if
  end if
  dim a, b, c
  select case wilds(1)
    case "purple"
      hndl.createspark(9123723)
    case "bright yellow"
      hndl.createspark("light yellow")
    case "sky blue", "sky-blue"
      hndl.createspark("sky blue")
    case "violet"
      hndl.createspark("violet")
    case "cobalt blue"
      hndl.createspark("cobalt blue")
    case "turquiose"
      hndl.createspark(13688896)
    case else
      a = getlinecount
      b = getlineinfo (a, 11)
      c = getstyleinfo (a, 2, 14)
      hndl.createspark (c)
  end select
end sub

sub OnPluginClose
  set hndl = nothing
end sub

sub SetPos (name, output, wilds)
  if isnumeric(wilds(1)) and isnumeric(wilds(2)) then
    Repos = "True"
    setvariable "PosX", wilds(1)
    setvariable "PosY", wilds(2)
    hndl.undock
    hndl.MoveTo Wilds(1), Wilds(2)
  else
    colournote "red", "black", "Error: 'MoveTo' requires numberic values."
  end if
end sub

sub SetSize
  if isnumeric(wilds(1)) and isnumeric(wilds(2)) then
    Repose = "True"
    setvariable "Width", wilds(1)
    setvariable "Height", widls(2)
    hndl.undock
    hndl.Resize wilds(1), wilds(2)
  else
    colournote "red", "black", "Error: 'Size' requires numberic values."
  end if
end sub
]]>
</script>


<!--  Plugin help  -->

<aliases>
  <alias
   script="OnHelp"
   match="MC_Firework:help"
   enabled="y"
  >
  </alias>
</aliases>

<script>
<![CDATA[
Sub OnHelp (sName, sLine, wildcards)
  world.Note world.GetPluginInfo (world.GetPluginID, 3)
End Sub
]]>
</script> 

</muclient>

This will cause the display to be closed completely about two minutes after the last firwork starts. It also lets you position the gadget where you want. However, there may be bugs in the script, since I haven't had a chance to do more than make sure the above plugin will actually install with the new changes.

David Haley USA Thu 13 Nov 2003 06:56 PM #12

Quote:
As to your comment Ksilyan, with VB.NET they apparently realized how patently stupid it is that you have to use API calls to get basic information about your own windows. For instance, while you can get the external size of the window, there is also an internal 'client' area that you are forced in VB6 to use API calls to aquire. However, to correctly resize control on a form, you often 'need' this information. Why? Because the title and menu bars both take up space that is not part of the 'client' area and the size of these things on most version of windows is dependent on settings in the registry, and worse still, under XP you can tell it to change the size of these things for every bloody program running. This info is a property of the form itself in VB.NET, but 'should' have been such even in VB6 imho. 50% of my code involves API calls that are not documented anywhere in the so called Professional Edition of VB6 I am using.

Umm, actually, Poromenos is right - you CAN get the size of the current window using form.ScaleWidth and form.ScaleHeight.

And no, changing those won't change the size of your form; that's what normal width and height are for.

Here's the thing: width and height are expressed in "twips" or whatever they're called, and of course this is not terribly useful for us... so you set the scale to pixels, and then ask for scalewidth and scaleheight. This should all be in the documentation; I'd be a little surprised if it wasn't in there (somewhere.)

Unfortunately I can't test this and show you how to do it anymore, since I have Visual Studio .NET now, but I know it's possible - I've done it before. :)

Didn't Microsoft release the .net framework for older OSes? It seems a little odd that they would actually sacrifice backwards compatibility... after all, so many of the problems with Microsoft software (at least, until XP I suppose, and obviously 2000, but that's a different branch of software) is the desire to be backwards compatible with things like DOS...

Edit:
After re-reading your post, I'm not exactly sure what your problem is... is it that the menu and title bars aren't part of the size reading VB6 gives you?

I've seen some pretty funky stuff in VB that uses ClientArea API calls to define forms with funny shapes, like donut forms you can see (and even click) through... but you seem to be doing something much simpler than that, and in your case, I believe the "external window size" and the "client area" are the same thing.

Shadowfyr USA Thu 13 Nov 2003 09:08 PM #13

Well. I am sure it is in the documentation. If it is described in a way that makes any sense however... lol I don't really have a problem specifically, except where it involves MS deciding to use bone headed syntax in VB or disabling features that any other language would let you do without all the hassles. Like you where saying with Twips, ScaleWidth and ScaleHeight are not as far as I am aware used by 'any' OS or even language except VB. Why then would any sane designer assume that a coder would know what to look for when trying to find them? lol

In any case my current problems are two fold:

1. The current method I use seems to have caused Mushclient to crash after about 2 hours or continuous API calls. This 'could' be do to problems with my own system.

2. The more 'sane' method of only responding to WM_SIZE, WM_MINMAXSIZE and WM_MOVE is not merely inconvenient, but apparently impossible to hook in VB, so I can't use them instead to reposition and size the window only when needed.

Of course if Mushclient could generate script events for these things and you could request its current window size and position from in scripting, I wouldn't have needed to enter into this nightmare in the first place. lol

Oh, and as far as I know .NET wasn't released for older OSs, unless it is for the more recent ones, since it relies heavilly on XP specific functions that are not available on the older OS versions.

David Haley USA Thu 13 Nov 2003 10:01 PM #14

I'm sure that there is an advantage to twips over pixels, otherwise they wouldn't have used twips in the first place. I know that MS does weird stuff, but come on, they're not THAT stupid. :-)

As for the .NET framework, the MS site claims that it works as far back as Win98:
http://www.microsoft.com/downloads/details.aspx?FamilyId=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en
That is a link to the .NET redistributable download.

http://msdn.microsoft.com/netframework/technologyinfo/howtoget/
That's a link to a more general page on how to get the framework.

I can't help you much more with the rest, since a) I don't know your system and b) I don't know much about responding to Windows messages from VB. :) I'm sure you can do it though... again, I would search on Google for "visual basic windows message hook" or something like that.

Shadowfyr USA Thu 13 Nov 2003 10:45 PM #15

Well.. I already went hunting. If you want to capture your 'own' messages you can subclass the window. However to do it for someone elses you need a hook. The problem is that hooks 'must' be dlls apparently and everything I have seen indicates that VB creates some sort of dll that isn't compatible with message hooks. I don't feel like digging into C++ just to make a dll that only gives me such a hook and the only one I have found so far that someone else made stops working after 30 days and they want $80 buck for it.

This logic I don't understand... You design a system component that thousands of people are probably going to use, virtually guarrentying that you will make a mint off it anyway, but no one can afford to use it because you charge them 4-5 times what they plan to sell their own product for?!? If I could slap down $20 bucks, I might be willing to buy the rights to use such a thing, but I refuse to pay $80 - $200 just for a component that is useless without the thousands of lines of code 'I' have to code to use it for anything.

This is like telling someone they need to pay you $50 for a chip to go in an electronics project, because you figure they are too stupid to buy two 50 cent chips and build the circuit themselves. I may be a bit lazy, but I am not completely stupid. lol

David Haley USA Thu 13 Nov 2003 10:58 PM #16

Well, I see your point, but in the meantime you're not actually using anything at all... :-) So the money they charge you is more for the convenience factor and the "it's already done" factor, than for the actual components themselves.

This is how it works for *tons* of software applications. Do you have any idea how much it would cost to license Quake3's graphics engine, and how much you make off the sale of one product?

Also, think of database applications. Obviously a database for C++ is useless without the thousands of lines you'd have to write. But does that make it stupid to sell the database? Granted, we're not talking about the same level of complexity, but still...

I think even Nick had to pay more to license his spellchecker than he makes by selling individual copies.

Heh, it's kind of hard to read your posts, because you use single quotes to emphasize things, where single quotes are normally used to quote things and asterisks are used to emphasize... so I keep reading your text as you quoting things (and thereby intending that I don't take it literally) when what you actually mean is to underline/emphasize that word. Follow conventions! :P

David Haley USA Thu 13 Nov 2003 11:00 PM #17

This seems to be exactly what you want, by the way... a way to intercept the messages that Windows is sending you:

http://www.thescarms.com/vbasic/subclassform.asp

My search was "visual basic hook message" and it was in the first 10 results...

Shadowfyr USA Fri 14 Nov 2003 12:33 AM #18

I wasn't aware there was such a convention... I see a lot of different ways people emphasize things, I just happen to use ''.

As for your link.. It is exactly the stuff I already found. It is useless for trapping the events from Mushclient's window, since you can only subclass a window which is in the same thread as the application doing it. In other words, you can only capture events for your own application, not anyone elses. There is a way to hook into the system somehow and do it, but I haven't found a single example of how to do that and the technique requires the process providing the hook to be a seperate .dll. However, as I said before, apparently something about the way VB creates dlls is incompatible with this method, even assuming I could find an example of using such a system hook.

In any case, making all this stuff work is complicated and a major mess, even without trying to trap such events. Since a great many people are likely to design stuff like this for Mushclient over time, it makes sense to me that such events should be trappable in Mushclient, where there is no need to worry about all the complicated work arounds. Odds are good that programs like zMud, which provide specialized plugin code to tie into user made dlls probably provide such information when request anyway. They would have to for such plugins to work right. I personally believe having the client provide these things makes a lot more sense, especially since there may be things you want to do like say:

sub OnClientMinimize
World.send "afk Sorry, but I had to leave for a moment."
end sub

Currently you can't even tell it happened *in* Mushclient, let alone pass that info on to an external program.

----

I do understand in a general sense about the cost of items though, it doesn't bug me that they charge money, just the scale. While I admit that in this case the problem is hard to find the solution to, since subclassing is useless in this case, the actual code is probably less that 20 lines total. If it did a dozen other things it *might* be worth it, or maybe not, since then I would be adding the bloat of all the extra junk as well. I expect to pay say $50 for a book on programming, I don't expect to pay $80 for a three page pamphlet. This is in my opinion not that different from what these people are trying to do and it loses them customers, not gains them, especially for something like this which is quite frankly easier to do other ways when developing complete projects and is at best a nitch product.

Magnum Canada Fri 14 Nov 2003 01:25 PM #19

At ShadowFyr's request, I have separated the Fireworks graphical program, and the plugin that uses it, into two separate files for download. Also, ShadowFyr sent me an update to the plugin.

Currently, you may download:
mc_firework.zip v.1.0 (The main graphical program)
aod_firework.zip v1.1 (The plugin for use on Ages of Despair MUD)

...from my website. http://www.magnumsworld.com/muds/