Hi there

I am making my own numerical keyboard popup, but I don't know if it is possible to pass control from the currently running function to a loaded function .

I want to be able to suspend the current "form" (for want of a better expression) while the keyboard form gathers it's data. Then when it is closed, control passes back to the main form.

I want the keyboard function to be reusable across a lot of different forms.

I am coming from a c# backround, and perhaps Lua can't do this.

Thanks for any help or suggestions.

JB

There are no forms in corona. You create display objects, assign listeners to them. You can think in a way that there is only one form.

If you want to pop up a keyboard, you can put keyboard objects in a function or in a module, and when you call it, you can make invisible other display objects, and show only keyboard objects.

There are group display objects which can contain other display objects. So, if you want to design your app in multiple forms, or screens, you can group display objects and then you can make visible / invisible these groups.

So if you are going to make a reusable keyboard screen, or keyboard form, you would probably would like to code it as a module, and put all of its visible objects into a group.

Because there are no forms or views in corona, you would better think in groups, make them visible or invisible according to your needs.

Thanks for that - I think I've got my head round the event-driven side of things.

The bit that I am unclear about is the logic of controlling the program flow from a loaded module. The keyboard pop-up will eventually finish either with a user-entry or cancel.

My current confusion is where to put the event handlers to control the keyboard, and how to pass back the "state" of the keyboard.

Still thinking it through.

JB

in c# you define the forms as classes, then you initialize the form and call its show() method, and it displays the form. then when you click on, say, a button, you initialize another form, and call its show() method. now you have two forms, you can keep both open, or you may close or hide the other.

I think your biggest confusion not comes from forms but from the non-object oriented structure of the lua.

lua is a prototype based language, and there are no classes. which means, it is not object oriented in real.

however, because of its simple and flexible structure, you can "simulate" object oriented methodology using, tables.

first, please check : http://developer.anscamobile.com/code/object-oriented-sample-game-framework

this is just one way to implement object oriented structure. there are other ways, just search google for something like "how to implement classes in lua".

second, check http://developer.anscamobile.com/code/director-class-10
this user-created library makes it easier to create multiscreen applications.

yesterday some other user released an alternative to director you may want to check it too : http://developer.anscamobile.com/code/scenemanager

the above just shows how people solve their problems. you may want to use them or develop your own solution.

for maximum freedom, and maximum reusability of your own code, you may want to create your own simple yet personal framework. because for now, corona does not define a structured and standard way to create multiscreen/multiview applications.

This is really useful.

I think you are right. I am used to the OO stuff of C sharp, and the ability for Forms to communicate with each other, and I am confused as to the cross-communication between a function in a module (which I have been playing with) and the corresponding events in the "calling" code.

A keyboard popup is a good example, because I can create the keyboard in a public function in a module, but allowing the keyboard to complete its functions and then indicate to the rest of the program that it is complete is what is giving me trouble. Easy in Csharp - not so obvious here! :-)

I will have to give this a lot more thought.

I am trying to use LUA and the Corona SDK to develop a business app rather than a game, so it's an interesting learning exercise!

Thanks again for your input - very much appreciated.

JB

I've also looked at the Director Class and I understand how that works, but it does not give provision for one "screen" or displaygroup to overlay another - it provides neat switching between groups... at least that's how it looks on first examination.

Scene Manager looks good as well... I shall investigate further.

JB