SolarStrike Software

I never really liked ncurses for a few reasons. For starters it's still a text display and if I remember correctly the scroll bar couldn't be used anymore to scroll back through output history.

I remember trying to add support for Window forms using a widget library, I don't remember which one, with limited success. The main problem I had was when using the form - especially the form menus - the script would freeze. I tried a few way to overcome this but finally gave up on it.

I had an idea though, there are programs that have embedded consoles. Is it possible to make micromacro an embedded console in a window application? And would it be possible to make it so a program running in the embedded console could access and manipulate the Window? Possibly even adding widgets such as text boxes and buttons?

The way I envision it working is it starts with a simple menu with options such as Load, Help, About etc. Then when you load a program the program adjusts the window for it's purposes, eg. RoMBot might create info fields with player name, health, waypoint loaded, coords etc. Then when the program ends it resets the window to it's default state. You could even create an interface that has everything you need and hide the console.

What do you think?

That's still something I intend to look into further eventually. I've considered a number of different approaches. The problem comes down to managing all the different resources and exposing them to Lua. It can be quite difficult to synchronize the threads--and GUI applications will make use of that extensively.

The good news is that I've been making some progress in that direction. Just recently I've been working on revamping the socket code to pack input into their own separate queues for better control and accessibility. This also comes with using its own set of mutexes to prevent the many different threads from having a royal rumble. There was a number of different chunks of code that weren't behaving correctly, and I assure you multi-threaded apps are no fun to debug. I've pushed it into the experimental branch and it has come out to be more work than I first envisioned. I am, however, learning a lot and getting things set up better for more future multi-threadedness. Hopefully, that making use of a proper GUI.

I still like the idea of the default "basic" set giving just the console. But, once a script requests to make use of a GUI, it could hide the console and take over the front-end. I'm thinking we will be able to have each button, input box, or whatever else all as seperate objects that are accessible via Lua (much like how the inputs and windows work in Ncurses), and that each of them can have their own set of callback events attached: onClick(), onHover(), onChange(), and so on. These callbacks would, in turn, launch a snippet of Lua code much in the same fashion that events are currently being passed. Does this seem reasonable? Does it even make any sense?

Yes it does. Sounds very exiting.

I'm thinking we'll be ready to have every button, input box, or no matter else all as seperate objects that area unit accessible via Lua.
much like however the inputs and windows add Ncurses.



_________________________________________________________
And I love to create friends,Because:Buy RS Gold to be along side friends
invited here:RS Gold