Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Lua ➜ Creating a GUI with Lua.
Creating a GUI with Lua.

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

Posted by Batista   (15 posts)  Bio
Date Wed 07 Jun 2006 06:26 AM (UTC)
Message
I'm looking to possibly create my own neat little GUI thing. The problem is, I have no idea how to get started. I've tried looking around the forums already but I can't find how to get started on something like this.

Does anyone know where I could find a good tutorial? Or, if possible, show me an example of the first steps I'd need to take?

Thanks!
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #1 on Wed 07 Jun 2006 07:14 AM (UTC)
Message
Lua can't create GUIs on its own. You would need a GUI toolkit that has bindings to Lua.

You can try wxLua, although it is non-trivial to set up, to say the least.

There's another GUI binding that is floating around, but I can't remember its name. Your best bet is probably to Google for "Lua GUI binding".
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #2 on Wed 07 Jun 2006 08:57 PM (UTC)
Message
I started doing something like that myself. Do you mean a stand-alone program that has a GUI interface? Or something else (like something that runs with MUSHclient)?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Batista   (15 posts)  Bio
Date Reply #3 on Wed 07 Jun 2006 11:46 PM (UTC)
Message
I'd like something that runs with MUSHclient. More or less, I want to play the game in a custom window but inside MUSHclient itself. Does that make sense?
Top
Posted by Ked   Russia  (524 posts)  Bio
Date Reply #4 on Thu 08 Jun 2006 02:17 AM (UTC)
Message
You'll probably still have to make a standalone program, which is tied in with Mushclient through UDP. Unless Nick can come up with a way to use threads or COM in Mushclient scripts that doesn't randomly crash.

In my experience, running a GUI app from within Mushclient is too messy.
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #5 on Thu 08 Jun 2006 06:41 PM (UTC)
Message
To be clear, running one "in" Mushclient isn't an accurate statement. Rather you are running it "in" the script space, which creates a whole can of worms and "can" cause crashes if the object isn't released properly, the script reloads, the object is closed manually, but can't inform the script it needs to be released, etc. And then there is the whole UDP issue, which I have posted several times about solving by fixing the issue that events can't be handled currently. Its a mess, and the solution isn't entirely clear. The only "working" ones I know of would involve a COM bridge, which Nick doesn't want to fiddle with (turns out trying to figure out how/why one even works requires a book not on ATL, but on the core OLE functions... Major waste of $60 bucks.) *or* the client has to override or give a replacement for CreateObject (or the similar function), which reads the COM objects internals, creates the needed connection points and finally exposes all of them, including the events, to the script system.

Problem is... Finding examples of either is nearly impossible, because the companies that know how to do them guard the secrets like a dragon's hoard, and everyone else just ignores what you are trying to do, and instead tells you to, "Just use IE or WSH." Like either of those solutions are not a) insecure, b) even more limited and c) just plain stupid in this case. Sigh...

I keep looking though. :(
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #6 on Thu 08 Jun 2006 09:40 PM (UTC)
Message
Quote:

More or less, I want to play the game in a custom window but inside MUSHclient itself.


I think people have made VBscript programs (controls?) that funnel things to/from MUSHclient via COM calls, however that tends to get a bit messy.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nexes   (65 posts)  Bio
Date Reply #7 on Thu 06 Jul 2006 07:58 PM (UTC)

Amended on Thu 06 Jul 2006 08:03 PM (UTC) by Nexes

Message
I also recommend a stand alone program. I myself used wxWidgets in C++ and UDP to communicate between the program and MUSHclient.

Having never used a COM bridge, or whatever, I can't really comment on whether or not it's better. But I can say I haven't had any real issues with UDP. So long as you're the only one making your plugin+program then there really should be no confusion over what a particular UDP packet means.

Using this method I was able to create the health, mana, endurance, and willpower bars for Achaea and they updated properly and such. I haven't gotten to a point where I need buttons yet, but I don't believe that will be a problem. So far UDP seems to be able to do everything I need, and might need, it to do.

Oh, if you do decide to use wxWidgets, I recommend you download wxDevC++ or wx-DevCpp, whichever it is, because trying to build the wxLibrary from source, and then tie it into devCpp on its own was a pain and I never got it to work properly. Instead, wx-Devcpp gives you devcpp with the wxWidgets library already incorporated within it.

For some reason I find all these libraries, GNU compilers, and stuff to be confusing *sigh*. It doesn't help that a lot of them expect you to be using Linux to build. So I had to get MSYS and type a bunch of commands that I didn't really understand. Really confusing. So yeah, just avoid that all and just get the premade stuff.
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #8 on Fri 07 Jul 2006 11:18 PM (UTC)
Message
Quote:
Having never used a COM bridge, or whatever, I can't really comment on whether or not it's better.


Lets put it this way.. All a COM bridge consists of is a jurry ridged solution to get "around" something scripts don't allow. Basically, all ActiveX components have two sets of interfaces:

QueryInteface - Used to get in-bound connection points, such as browser.browse "http:\myurl" or properties, such as mystatus = browser.status.

Connection points - Used to get *out bound* connections, such as OnPageLoaded.

The problem is basically this, script engines do not, themselves, give access to the later interface. Some languages and tools like MFC of VB *hide* this interface, assuming that you know, "before" the program is compiled, what objects you are going to use. But every ActiveX object/application you create has these connection systems in them, assuming you provide the correct "FireEvent(blah)" or equivalent commands in them for talking to the thing that use them.

To use the 'browser' object as an example, some place in it is code like this:

if finished fireevent (PageLoaded);

And some place in the connection points is an entry that says, "IID_OnPageLoaded". Some place in MFC is code that, if you add a 'broswer' control to your program does:

set brctl = createobject("browser")
brctl::Advise (IID_OnPageLoaded, GetRef("OnPageLoad"))

and later on, when it needs to die, does:

brctl::UnAdvise (IID_OnPageLoaded, GetRef("OnPageLoad"))
set brctl = null

Or, something roughly like that. This is hidden under the hood, where you can't see it. A COM bridge simply restores to you the ability to do the Advise and Unadvise steps yourself, so that objects you want to add "after" the program is compiled, can talk to yours.

IE and some other clients, for which engines like VBScript and JScript where developed, already "have" these bridges in them. The stand alone .EXEs for things like Lua and Python, as well as wscript, also contain such bridges. But there seems to be an assumption that a) the way they work is so obvious anyone can do it (which might be true if people coded raw COM, instead of using MFC, etc.) or that b) the script is going to be running in something that already has one, so it doesn't matter.

Basically, the functions needed are built into "ever" ActiveX that provides events, by default, they are just hidden from view in 90% of the situations where people write code. :( And yes, imho, they should work better, if for no other reason that they are part of the same system you are already using to create and talk to the ActiveX programs in the first place.
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #9 on Sat 08 Jul 2006 01:10 AM (UTC)
Message
One of my problems with COM and MFC is that the MFC wizard hides from you a lot of the implementation detail. Because of this I am not really certain how a lot of it works, and browsing some of the MSDN articles only confirm my thought that doing something that is not provided "out of the box" as a wizard, is not at all easy.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #10 on Sat 08 Jul 2006 05:26 PM (UTC)

Amended on Sat 08 Jul 2006 06:19 PM (UTC) by Shadowfyr

Message
Snort! I think they write their documentation that way intentionally Nick. As I said in another thread, they never provide clear "examples" of how the heck anything works. If you followed their MSDN documentation, just trying to successfully print, "I am an idiot!", to a form would take a week to figure out. Not the least because they also assume you will be using VC++, so every needed flag value, ID, or structure needed to get data from them is, "buried someplace in the nice headers we provide for C++ users." Completely stupid if you are trying to do something like linking in API calls to VB, for example.

Case in point, it took me three days to find all the pieces I needed to make the Firework gadget I created a while back, because in the end I have to ignore MS' documentation of the API calls needed, and find specific examples in other parts of the web that could show me how the heck to do it. It turned out to require all of 3 API definitions and about 10 lines of actual code. The MSDN made it look like I needed to build a bloody monolith to do it.

The same is true with COM. Actually reading the books on the subject, the means to do it seems fairly straight forward, if still frustratingly badly documented, even in the books, imho. The last time I tried to look at the MSDN or **official** sources on the subject I found myself standing on the precipice of a literal rabbit whole and wondering why the world seemed to be shrinking. In MS' world, it seems you can't even blow your nose without them insisting that the *right way* is while standing on your head and singing the Microsoft corporate anthem. I am not suprised that most people's reaction is, "Good lord! Why even bother? I will just let MFC blow it for me." ;)
Top
Posted by Nick Gammon   Australia  (23,120 posts)  Bio   Forum Administrator
Date Reply #11 on Sat 08 Jul 2006 09:43 PM (UTC)
Message
Quote:

I think they write their documentation that way intentionally Nick.


There are certainly times when I have thought that too. A while back when I was trying to understand STL I looked at the "help" provided by Microsoft as part of shipping its compiler. Most of the help for STL was along these lines:


deque::const_iterator

typedef T1 const_iterator;

The type describes an object that can serve as a constant random-access iterator for the controlled sequence. It is described here as a synonym for the unspecified type T1.


Frankly, if that helps you understand anything (if you are trying to learn what you might use a const_iterator for) then you are smarter than me.

However their documentation for their own libraries (queue manipulation, lists etc.) are much better, replete with discussions about why you might use them, helpful examples, and so on.

One theme seems to run through a lot of their documentation and code in general: "Don't use industry standards, do it the Microsoft way".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #12 on Sat 08 Jul 2006 09:52 PM (UTC)
Message
Yes, the Microsoft STL documentation is notoriously bad. In fact, I've found that the best STL introduction (as opposed to reference) is the book you recommended, Nick, by Josuttis. But, yes, their own libraries are very well documented, with examples, explanations; sometimes even so well documented that it's too much to go through for a simple reference! :)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #13 on Sun 09 Jul 2006 05:44 PM (UTC)
Message
I also cheated, when designing me fireworks gadget. I eventually found and used this:

http://www.allapi.net/agnet/apiguide.shtml

MY only major complaint with it is the same I have with MS documentation. While it gives basic examples for VB, since its intended to help people get at the API under that, it fails to list examples for "all" functions or notes on what the flag values are for doing most things. You invariably have to go hunting through either the VC++ headers for the values or google for them anyway. :(
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,819 views.

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

Go to topic:           Search the forum

[Go to top] top

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

Home