wxLua - StatusBar #3

Posted by Faux on Thu 13 Jan 2005 01:21 AM — 7 posts, 37,936 views.

Faux United Kingdom Thu 13 Jan 2005 01:21 AM #0

Hey, not that there's anything wrong with the UPD way, but..

And.. not that there would have been anything wrong with the PHP FFI way, had it worked..

The wxLua way!

For example..
http://faux.sison.nl/luabar.png

(The little hp window.. isn't it cute?)

Edit: It's even cuter when you make it smaller, btw =)

Note that there's only one window here as a beta test.. the stability isn't great at the moment, and some things don't work simply because I'm using someone else's old binary of the library.

It also isn't possibly to distribute as a plugin because of:

The fact that it needs the wxLua.dll library file.
The fact that it needs to be able to load the wxLua.dll file, which, by default, MUSH prevents.

However, the code I have to make this work:

First, pre-setup..

MUSHDIR\wxlua.lua:


wx = nil
if loadlib ~= nil then


Note ("loadlib ~= nil");


    local luaopen, osError, errorDesc, fileName
    fileName = "wxLua.dll"
    luaopen, osError, errorDesc = loadlib(fileName, "wxLua")
    if luaopen ~= nil then
        wx = luaopen()
        if wx == nil then
            Note ("Error: Call to LuaOpen() in "..fileName.." failed.")
            error("Call to LuaOpen() in "..fileName.." failed.")
        else
            Note ("wxLua version: "..wx.Version)
        end
    else
    	Note ("Error: Unable to open "..fileName..".\nWindows reports: "..osError)
        error("\nUnable to open "..fileName..".\nWindows reports: "..osError)
    end
end

This requires wxLua.dll (and it's support files) to be in the MUSH directory.

http://homepage.ntlworld.com/johanne.winwood/wxLuaBin26.242.zip

Now the actual code..

Part of the script file:


frame = nil
gauge = nil
function winblow()

	require "wxLua.lua"
	frame = wx.wxFrame( wx.wxNull, 
				-1, 
				"hp", 
				wx.wxPoint(-1, -1), 
				wx.wxSize(200, 40), 
				wx.wxFRAME_TOOL_WINDOW + wx.wxCAPTION + wx.wxSTAY_ON_TOP + wx.wxRESIZE_BORDER)

	frame:Show(wx.TRUE)
	gauge = wx.wxGauge( frame, -1, 20, wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxGA_SMOOTH)
end

The trigger. (as you may have guessed this is for Discworld, but I hope you can guess what's going on.):


<triggers>
  <trigger
   enabled="y"
   match="^Hp: ([0-9]+)\(([0-9]+)\)"
   regexp="y"
   send_to="12"
   sequence="95"
  >
  <send>frame:SetTitle("Hp! - %1/%2 - (" .. ((%1/%2)*100) .. "\%)" )
gauge:SetRange(%2)
gauge:SetValue(%1)</send>
  </trigger>
</triggers>

Just to make that even less confusing, the "prompt" looks something like:

Hp: 2025(2025)  Gp: 322(337)  Xp: 72993

As you may have noticed this code does nothing by itself, you have to call the winblow() code to get it going.

See the stability notes down there..

Other notes..

For the loadlib code to work you need to modify the Sandbox that MUSH runs by default. This is specified in FILE\General Preferences, which took me a while to find.
My Sandbox simply looks like:
```
function MakeSandbox ()
end
```
Note that this is a bad idea if you don't read code before using it.
Stability: Re-loading the script file while a wxLua dialog is on the screen either hangs or disappears MUSH. Your guess is as good as mine. [reference-to-frame]:Destroy() doesn't work as expected (doesn't work at all). Maybe it's just my system.
MUSH seems to be using a really random verson of Lua, as I have a version that requires only 1 dll and contains the functions in both.. it also appears to be completely backwards compatabile as I have it running instead of the default at the moment.
Building wxLua: wxLua requires you to have built wxWidgets, which I've managed using the C++ Programmers Toolkit and SDK from microsoft (not trivial), but wxLua doens't come with a compatiable makefile, so I can't rebuild.

-- Faux the ....

David Haley USA Thu 13 Jan 2005 01:31 AM #1

That's pretty cute - seems like it would be a great start to solving all these problems about extra windows.

About the sandbox though, I thought you could set up a sandbox per plugin? Then you could just change only this plugin's sandbox, not everything else's too - which, I agree, isn't necessarily such a good thing.

Faux United Kingdom Thu 13 Jan 2005 03:24 AM #2

I think the code is already there, I can't remember.. (I deleted all mine), but you could have, say,


function query_password()
{
	return "monkeybob";
}

in the plug-in, and, when it comes to setting up the sandbox, MUSH (well, the lua engine) checks the password, and if it doesn't match, then it sandboxes the application.

This'd still be something the end user would have to hard code, though.. unless the password was randomly allocated on install/the license code/a `hardware id`/.. etc.?

Unless we get on to microsoft-level code signing.. what else?

The other option, of course, is getting this working well enough to make it worth including in the MUSH distribution package..?

Btw, did you get it working? I've been "hacking" MUSH/wx/lua for about 2 weeks to get this going.. not sure if the instructions are complete.

Nick Gammon Australia Forum Administrator Sat 15 Jan 2005 09:46 PM #3

Quote:

MUSH seems to be using a really random verson of Lua ...

It is the latest version at present, 5.0.2, as downloaded from their site. I rebuilt it to make 2 DLLs, the core Lua and the Lua library (lua.dll lualib.dll).

There don't seem to be standards for how to distribute the lua dlls, the luasocket implementation did it slightly differently too.

Faux United Kingdom Mon 17 Jan 2005 04:59 AM #4

In the end I just re-wrote the import tables on anything I didn't like. Hehehe.

Onoitsu2 USA Tue 12 Feb 2008 07:32 PM #5

I have resurrected this thread, as I stumbled across it from a Google search.

I have been able to create a separate window using wxLua, using require("wx"), and can even update it and several other things. The only snag is that it disabled ALL accelerators as well as other keyboard related functions in Mushclient when displayed. You can type in the command box and send it to the world, but you cannot scroll back nor use the numpad not any accelerators/macros. I was searching and think I may have found a way to successfully navigate this issue, but am TERRIBLE with coroutines. You would have to create a coroutine for the main() function, I think...

Here is my code as of yet...

Quote:


require("wx")

function main()
frame = nil
gauge = nil
frame = wx.wxFrame(wx.NULL, 
				-1, 
				"test", 
				wx.wxPoint(-1, -1), 
				wx.wxSize(200, 40), 
				wx.wxSTAY_ON_TOP)
-- create a simple file menu so you can exit the program nicely
local fileMenu = wx.wxMenu()
fileMenu:Append(wx.wxID_EXIT, "E&xit", "Quit the program")
local menuBar = wx.wxMenuBar()
menuBar:Append(fileMenu, "&File")
frame:SetMenuBar(menuBar)

function clo(event)
  frame:Close(true)
  frame:Destroy()
end -- function clo

frame:Connect(wx.wxID_EXIT, wx.wxEVT_COMMAND_MENU_SELECTED,
              clo )

frame:Connect(wx.wxEVT_IDLE,function(event)
          event:RequestMore()
          event:Skip()
        end)
	gauge = wx.wxGauge( frame, -1, 20, wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxGA_SMOOTH)

frame:Show(true)
end -- main

main()

-- Call wx.wxGetApp():MainLoop() last to start the wxWidgets event loop,
-- otherwise the wxLua program will exit immediately.
-- Does nothing if running from wxLua, wxLuaFreeze, or wxLuaEdit since the
-- MainLoop is already running or will be started by the C++ program.
wx.wxGetApp():MainLoop()

I am able to update the gauge using the syntax previously mentioned in the thread, but have had to tweak some things to get it to work in the long run, as well as having to alter the sandbox, which I just tell it to trust all worlds.

I also have attempted to connect to the IDLE state something that SHOULD get and process other events, BUT is not, although SOMEONE with more experience than I have might be able to have it properly forward things to the message pump, or just cram the entire "loop" into a coroutine, which would free Mushclient up to process things like usual.

Visit this URL, and download the file in the Windows section, via the link labeled "package"
http://wxlua.sourceforge.net/download.php

Extract ALL dlls located in the bin folder within the archive, to the Mushclient folder, and then you can use wxLua as a module, albeit a little buggy as mentioned...

-Onoitsu2

Shadowfyr USA Wed 13 Feb 2008 04:26 PM #6

Actually, the whole problem comes down to that message pump. I have explored a bit and found that there is "apparently" a means to mix some ATL into MFC apps to "bridge" this, since MFC's standard way to handle such things is to *only* allow early bound events, via *its own* internal managers. Obviously, this causes a huge headache when using any sort of scripts, since a) the scripts are late bound, and so are any objects they create. This frells communications in both directions, since the MFC pump recieves the events going both directions (if I understand the issue right) and then has no clue what they belong to, or how to get them there, so just ignores them. This may even be why things like "Destroy()" on some objects are not automatically called, since, while the script knows its gotten a "I am unloading you" event, the object doesn't get one, so the script dies, but the object remains in memory, with nothing connected to it. But, that is only a guess, so I am not really sure what is going one in those cases.

Basically, the only fix is so arcane that I have been hunting for it for years and never quite finding a clear piece of example code that shows how to do it, or rewriting the client in something that doesn't tie your hands and feet to a chair, then beat you when you want to handle late bound objects. It might simply be easier to port to something like mono, which exists for Windows as well, and how that it, and its compiler, is fast enough to produce an equivalent client, and would also make things work in Linux and others as well. But, doing that means translating all the blasted MFC calls into code that does the same things as the current client.

Basically, there are a huge number of things only solvable by either fixing the big hairy ball of problems with late binding and objects that MFC creates, or by bypassing it using stuff like UDP. The only problem being, you can't even do the later if the 0bjects you are making are done via wxLua, or the like, since you *still* can't handle events internally to the Lua system. Only stand alone objects, compiled as their own applications, can use UDP to return events, since they are the only thing able to handle their own events to *see* them, and respond via that method. Others, including ones from .dlls, can't do jack, probably even with their own events internally, since they rely on Mushclient's sealed and inaccessible message pump to *tell* them something happened.

Mind you, there is one other solution. Bloat the client with code to provide the windows, buttons, images, etc., using *its* internal pump and support, assuming you can even do that right in MFC, since, I presume, even cloned from known internal objects, those would still be late bound and therefor not in the pumps support structure... I don't know who it was that originally thought, "Heh, lets make something called MFC, so its *easier* to code.", but they must have also invented child proof bottle caps. lol