Creating a modal dialog in Smart Mobile Studio

Just a quick tip for all you SMS hackers out there. Have you ever wanted to create a modal dialog for your SMS applications? Well, the bad news is that JavaScript doesnt know a modal form if it’s life depended on it — but the good news is, that you can force the user to take notice, creating the same desired affect.

The way to make the user take notice is, naturally, to make it impossible for him/her to continue doing anything until your dialog is released. Now there are many ways to do this, from the extremely anoying to the almost pointless. In our case we will be simple and to the point (which I think most users favour) and simply create a block-box.

The block-box approach

What is a block-box? Well, it’s actually just something that is semi-transparent and covers the whole display — blocking all user input from ever reaching underlying components. Clever right?

You will find the class TW3BlockBox defined in W3Application.pas and all it does is to fill the display completely with a black, semi-transparent panel. If you have ever user TApplication.ShowDialog then you know what it looks like.
Creating a block box is as simple as:

  FBlocker := TW3BlockBox.Create(Application.Display);
  FBlocker.SetBounds(0,0,Application.Display.Width,Application.Display.Height);
  FBlocker.BringToFront;

And voila, you have effectively blocked the entire display from getting any user-input events (so make sure your panel or dialog release the FBlocker instance, or you will never get out again.

When you create your dialog, remember to use FBlocker as parent (!)

Also, if you are worrying about “oh what if i forget to release it? What about memory”, well that’s not a problem. With the block-box in place the user cannot do anything until you release it (unless you have a timer that kicks in and does something fantastically illegal) – and secondly, releasing your instance is very simple too.

I suggest you do like me, and isolate your dialog in a class. Create the block-box inside your constructor. Then have a “ok” button (or whatever you want the user to do) and in that button you just go:

Procedure TMyDialog.W3Button2Click(Sender:TObject)
Begin
  if assigned(FOnDialogDone) then
  FOnDialogDone(self,fmOk);

  w3_callback( procedure ()
  begin
  self.free;
  end, 100);
end;

This will call back to the main app with your results, and gracefully release the dialog 100ms later. W3_Callback is important because it gives the browser time to update stuff, and since we now write async code – that is a very important factor. How you sculpt the dialog and/or events is up to you. Also, javascript is managed, so there is no such thing as memory loss (in theory) unless you create 1 million nested divs and just keep on going 🙂

Built in modal functions

The RTL contains functionality for dealing with modal dialogs in a more uniform way. If you head over to Primoz’s website you will find a full tutorial on using that functionality: http://www.smartprogrammer.org/2013/04/new-in-smart-11-modal-dialogs.html 

Enjoy!

Getting a handle on things

This is a nice addition to QTXLibrary, and perhaps it will one day find it’s way into the Smart RTL.

Under native languages, a Handle is just a longword number. It is usually a reference number you get when you call a DLL driver (like a parking slip, to remember where you parked), a graphics library or the operative system (e.g “window handle”, “graphics context handle” and various other handles). In some rare cases a handle is the numeric version of a pointer – but hopefully everyone has left that practice back in the late 90’s early 2k’s.

Smart Mobile Studio Handles

Under smart mobile studio a handle is a reference, in most cases it’s a reference handle to either a HTML element (usually a DIV element, which is the basis for 90% of all SMS controls), a timer (returned by setTimeOut() in JavaScript) or a graphics context. The latter two are hardly ever accessed directly – except by advanced programmers who want to link to external libraries.

So, what does all of these handles have in common? Well, they all have to be tested before used, that’s one thing they have in common. And also, even if the handle is valid – there is no guarantee that they are part of the visible DOM. That’s another thing they all have in common.

A graphics context can be created “off screen”, so it’s not connected to a HTML element and thus invisible. A DIV element (which is wrapped by TW3CustomControl) can likewise be created “off screen” by providing NIL as a parameter to the constructor. This means that it’s valid and ready to be used — but no visible output can be measured from it.

Another thing handles have in common, is that we tend to do stuff with them when they become valid. For instance, it’s typical to attach events which executes whenever the document has loaded — and also whenever a HTML elements has been created and attached to the DOM.

When you sum up the chores for handles, what we get is a very small but effective handle-helper which will make tedious tests trivial. And it looks like this:

type

  TQTXHandleHelper = helper for THandle
  public
    function  Valid:Boolean;
    function  Ready:Boolean;
    procedure ReadyExecute(OnReady:TProcedureRef);

    Function  Defined:Boolean;
    function  Equals(const aHandle:THandle):Boolean;
    function  Parent:THandle;
    function  Root:THandle;
  end;

//############################################################################
// TQTXHandleHelper
//############################################################################

function TQTXHandleHelper.Root:THandle;
var
  mAncestor:  THandle;
Begin
  if self.valid then
  Begin
    while (mAncestor.parentNode) do
    result:=mAncestor.parentNode;
  end else
  result:=undefined;
end;

Function TQTXHandleHelper.Defined:Boolean;
Begin
  asm
    @result = !(self == undefined);
  end;
end;

function TQTXHandleHelper.Valid:Boolean;
Begin
  asm
    @Result = !( (@self == undefined) || (@self == null) );
  end;
end;

function TQTXHandleHelper.Parent:THandle;
Begin
  if self.valid then
  result:=self.parentNode else
  result:=undefined;
end;

function TQTXHandleHelper.Ready:Boolean;
Begin
  result:=self.Valid and TQTXTools.getElementInDOM(self);
end;

function TQTXHandleHelper.Equals(const aHandle:THandle):Boolean;
Begin
  asm
    @result = (@self == @aHandle);
  end;
end;

procedure TQTXHandleHelper.ReadyExecute(OnReady:TProcedureRef);
Begin
  if Valid then
  begin
    if assigned(OnReady) then
    Begin
      (* Element already in DOM? Execute now *)
      if Ready then
      OnReady() else

      (* Try again in 100ms *)
      w3_callback(
        procedure ()
        begin
          self.ReadyExecute(OnReady);
        end,100);
    end;
  end;
end;

Valid

The valid function checks if the handle is valid. Under JavaScript that means not just to check for “null” – but also to check for “unassigned”.

Ready

This is a very important check. It tests if the handle has been injected into the DOM and that it can actually be operated on. You must always check the readiness of a handle before you attempt to alter an element.

ReadyExecute

This is typically used in constructors, where you can attach an anonymous procedure to execute whenever the handle becomes ready. Excellent procedure to use for components that needs a “nudge” to trigger an internal resize to layout the child elements.

Defined

Check that the handle is not undefined (unassigned).

Equals

Compares the present handle with another handle, returns true if the handle is identical.

Parent

Returns the parent (owner) of the element a handle represents. For elements living on a form, the form handle is returned since that is the parent of the child elements.

Root

Returns the topmost root of an element. For elements not yet injected into the DOM this will be NIL, for elements injected this will either be document or the host container for the smart app.

Using the helper

The helper is extremely easy to use. Once you include the QTXUtils.pas unit, all handles will support the helper. And now you can write more clearly accessible code as such:

if  ObjectReady //constructor complete? 
and Handle.Ready then //object injected into DOM?
Begin
  self.fxZoomIn(0.3); //Use CSS3 effect
end;

Enjoy!