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


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Plugins
. . -> [Subject]  Firework Gadget

Firework Gadget

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


Pages: 1 2  

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Wed 12 Nov 2003 02:58 AM (UTC)
Message
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
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #1 on Wed 12 Nov 2003 03:12 AM (UTC)
Message
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.

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 #2 on Wed 12 Nov 2003 04:30 AM (UTC)
Message
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. ;)
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #3 on Wed 12 Nov 2003 04:38 AM (UTC)
Message
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".

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,990 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Wed 12 Nov 2003 05:08 AM (UTC)
Message

  • 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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Reply #5 on Wed 12 Nov 2003 10:20 AM (UTC)
Message
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. :)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #6 on Wed 12 Nov 2003 08:03 PM (UTC)
Message
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
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #7 on Wed 12 Nov 2003 08:06 PM (UTC)
Message
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
[Go to top] top

Posted by Poromenos   Greece  (1,037 posts)  [Biography] bio
Date Reply #8 on Wed 12 Nov 2003 09:35 PM (UTC)
Message
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...

Vidi, Vici, Veni.
http://porocrom.poromenos.org/ Read it!
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #9 on Wed 12 Nov 2003 09:43 PM (UTC)
Message
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. :(
[Go to top] top

Posted by Magnum   Canada  (580 posts)  [Biography] bio
Date Reply #10 on Thu 13 Nov 2003 02:26 PM (UTC)
Message
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. :)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
[Go to top] top

Posted by Shadowfyr   USA  (1,786 posts)  [Biography] bio
Date Reply #11 on Thu 13 Nov 2003 04:47 PM (UTC)

Amended on Thu 13 Nov 2003 06:27 PM (UTC) by Shadowfyr

Message
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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #12 on Thu 13 Nov 2003 06:56 PM (UTC)

Amended on Thu 13 Nov 2003 06:58 PM (UTC) by David Haley

Message
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.

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 #13 on Thu 13 Nov 2003 09:08 PM (UTC)

Amended on Thu 13 Nov 2003 09:10 PM (UTC) by Shadowfyr

Message
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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #14 on Thu 13 Nov 2003 10:01 PM (UTC)
Message
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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[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.


50,170 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

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]