B4A Library [Lib] BetterDialogs

I tried to improve the most useful dialogs of the Dialogs library. In my version, HTML tags are interpreted (even in the text of buttons), the InputBox uses a Masked EditText and has more options, you can check if the input is valid before closing the dialog, and the CustomDialog is fully customizable. I also solved an issue with the virtual keyboard.

MsgBox (under Gingerbread and JellyBean):

InputBox (under Gingerbread and JellyBean):

CustomDialog (under Gingerbread and JellyBean):

Another CustomDialog (under Gingerbread and JellyBean):

v1.1:
- I added a CloseDialog function;
- I added a margin parameter to the custom dialog.

v1.2:
- I fixed a bug in InputBox when there's a default value;
- I added the BackKeyPressed event for custom dialogs.

v1.3:
- I added a PasswordMode option to the InputBox;
- I added a CancelOnTouchOutside option.

v1.4:
- I added a CursorPosition option to the InputBox.

v2.0:
- I moved the CustomDialog parameters to the BD_CustomDlgParams class.
- I added two new parameters: Duration and DialogGravity.
- I removed the Margin parameter and added the MarginHeight parameter (to be used when Gravity is set to TOP).
- The BodyWidth and BodyHeight parameters defines now accurately the size of the dialog body.

v2.1:
- I added a "closing" event raised just before a custom dialog is dismissed. You can cancel the closure by returning False.

v2.11:
- I added the "DlgResponse" parameter to the Closing event.

This library does not work with Android versions < 2.
It requires another library: Masked EditText

 

[Erel]

Are you using B4A v3.82?

 

[Informatix]

It seems that the problem is fixed with a version where I just changed a bit in each class to be recognized as a Java 6 library. I'm going to replace the file in the first post but I won't do that in the future. Everybody will have to update its configuration.

 

[MMORETTI964]

If the library was compiled with Java 7 then you need to:
- Reference Java 7 under Tools - Configure Paths.
- Use B4A v3.82+.

I use it:
C:\Program Files (x86)\Java\jdk1.7.0_03\bin\javac.exe

But I discovered I used 3.80.
In another PC of another my collegue (using 3.82) works fine.
I launch an update 4 all.

Thank you to all.

 

[MMORETTI964]

It is quite normal that a keyboard opens when you enter an EditText. If you want that your text cannot be edited with the keyboard (and thus avoid opening it), use my MaskedEditText lib and set ReadOnly to true. You will only be able to set a new text programmatically.

I try to use MaskedEditText but:
- Keyboard opens when you click inside edittext (it's true: you cannot input text but is really ugly ).
- As I need white background cursor vanish on some devices (is blank and you cannot change it programatically).

- Is for that I use a Timer for hiding keyboard
- In an EditText I can inflat the xml (don't know if I could make the same with MaskedEditText).

 

[Kevin]

I'm not sure to understand.

Would it be possible to use your built-in dialogs (such as MsgBox) but with the added ability to use a custom title and custom buttons like we can in your custom dialog?

I like the idea of being able to use custom buttons but then we can't use the automatic sizing & scrolling ability of the MsgBox.

 

[Informatix]

I try to use MaskedEditText but:
- Keyboard opens when you click inside edittext (it's true: you cannot input text but is really ugly ).
- As I need white background cursor vanish on some devices (is blank and you cannot change it programatically).

- Is for that I use a Timer for hiding keyboard
- In an EditText I can inflat the xml (don't know if I could make the same with MaskedEditText).

In the demo, if you click on the read-only EditText, no keyboard opens. But my comment was wrong; the reason is because InputType is set to None, not because of the ReadOnly setting. I forgot that.
The look of the EditText is the one set in the Manifest (the Android 2 style). You can change it (set another SDK version).
Masked EditText is an EditText (it's a subclass of ET), so all what you can do with an EditText can be done with my library.

I won't add a timer to the custom dialog, except the one that I added to dismiss the dialog, because it will have no usefulness for 99% of users and some of them will wonder why my custom dialog handles a timer. Moreover, what you ask is not an elegant way to handle the case (it's a trick, and I wonder how you block the user from using the clipboard to paste text into your EditText from a previous selection in another EditText).

 

[Informatix]

Would it be possible to use your built-in dialogs (such as MsgBox) but with the added ability to use a custom title and custom buttons like we can in your custom dialog?

I like the idea of being able to use custom buttons but then we can't use the automatic sizing & scrolling ability of the MsgBox.

To keep the scrolling feature, just place your views in a ScrollView and set the DialogBody parameter to this ScrollView.

 

[MMORETTI964]

In the demo, if you click on the read-only EditText, no keyboard opens. But my comment was wrong; the reason is because InputType is set to None, not because of the ReadOnly setting. I forgot that.
The look of the EditText is the one set in the Manifest (the Android 2 style). You can change it (set another SDK version).
Masked EditText is an EditText (it's a subclass of ET), so all what you can do with an EditText can be done with my library.

I won't add a timer to the custom dialog, except the one that I added to dismiss the dialog, because it will have no usefulness for 99% of users and some of them will wonder why my custom dialog handles a timer. Moreover, what you ask is not an elegant way to handle the case (it's a trick, and I wonder how you block the user from using the clipboard to paste text into your EditText from a previous selection in another EditText).

Yep... You're absolutely right but...
Unfortunately I don't know how:
- Make the cursor visible (is the cursor visible if I make InputType = None?).

I've edited your sample to see what - I'd - like (from the programmer's point of view)
the screenshot is the final result (in my program).

 

[TheMightySwe]

Hi, i'm using BD in some dialogs in my project, now I have connected a CipherLap Barcode Scanner to the tablet. For some reason does not the on screen keyboard show anymore.

Is what a setting in Android or is it something in BD code?

 

[MMORETTI964]

Yep... You're absolutely right but...
Unfortunately I don't know how:
- Make the cursor visible (is the cursor visible if I make InputType = None?).

I've edited your sample to see what - I'd - like (from the programmer's point of view)
the screenshot is the final result (in my program).

View attachment 28460

I've found a little bad behaviour.
When I have fullscreen = true and includetitle=false the 100%y seems cover more than the lenght of the dialog.
See the sample changed to see it.

 

[Informatix]

Yep... You're absolutely right but...
Unfortunately I don't know how:
- Make the cursor visible (is the cursor visible if I make InputType = None?).

I've edited your sample to see what - I'd - like (from the programmer's point of view)
the screenshot is the final result (in my program).

View attachment 28460

IMHO this dialog should not be modal. Modal dialogs should be used only when you want to alert the user (error report, warning) or you need an important information before continuing (like a password). I can't see why you would have to block a running code to display a calc. You should better do a standard dialog with a panel. If you want prevent the user from clicking on the interface around the dialog, disable this interface. The simplest way is to add a panel between the dialog and all other views. Moreover, with a dialog made this way, you should have no problem to hide the keyboard if it pops up.

 

[Informatix]

Hi, i'm using BD in some dialogs in my project, now I have connected a CipherLap Barcode Scanner to the tablet. For some reason does not the on screen keyboard show anymore.

Is what a setting in Android or is it something in BD code?

If your hardware is recognized as an input hardware, it wouldn't be surprising that the virtual keyboard is disabled. The BD library does not do anything special to open the keyboard, it just sets the mode of the virtual keyboard to SOFT_INPUT_STATE_ALWAYS_VISIBLE with setSoftInputMode.

 

[Informatix]

I've found a little bad behaviour.
When I have fullscreen = true and includetitle=false the 100%y seems cover more than the lenght of the dialog.
See the sample changed to see it.

Maybe you missed an important change introduced in the new version:
- The BodyWidth and BodyHeight parameters defines now accurately the size of the dialog body.
The dialog has a frame and this frame takes some place. The title and the buttons also. 160dip should be enough for all this (except maybe on Samsung devices because of their changes to the Android OS), so your maximum body height should be 100%y - 160dip, as in the demo. With no title and no buttons, 100%y - 15dip should be fine.

 

[MMORETTI964]

T

Maybe you missed an important change introduced in the new version:
- The BodyWidth and BodyHeight parameters defines now accurately the size of the dialog body.
The dialog has a frame and this frame takes some place. The title and the buttons also. 160dip should be enough for all this (except maybe on Samsung devices because of their changes to the Android OS), so your maximum body height should be 100%y - 160dip, as in the demo. With no title and no buttons, 100%y - 15dip should be fine.

Thank you!!!

 

[MMORETTI964]

IMHO this dialog should not be modal. Modal dialogs should be used only when you want to alert the user (error report, warning) or you need an important information before continuing (like a password). I can't see why you would have to block a running code to display a calc. You should better do a standard dialog with a panel. If you want prevent the user from clicking on the interface around the dialog, disable this interface. The simplest way is to add a panel between the dialog and all other views. Moreover, with a dialog made this way, you should have no problem to hide the keyboard if it pops up.

Yes I'd already opted 4 this option (before I saw BD).
However for easier programming having a custom input numeric acting in code as a modal dialog would be fine.
In our case we call the non-modal dialog, stop execution and restart execution at the end-dialog event.
However...
If I make some java timer and add a library do you think I can enter in my timer event even when your modal dialog is on?
Thanks 4 your patience.

 

[Informatix]

Yes I'd already opted 4 this option (before I saw BD).
However for easier programming having a custom input numeric acting in code as a modal dialog would be fine.
In our case we call the non-modal dialog, stop execution and restart execution at the end-dialog event.
However...
If I make some java timer and add a library do you think I can enter in my timer event even when your modal dialog is on?
Thanks 4 your patience.

Maybe you should reconsider the former option because the big problem in your case is that you need to know the window that contains your EditText to hide the keyboard and this window cannot be known before calling CustomDialog(). Once the dialog is displayed, many events won't work because these messages are delayed by B4A (but not all or you would get an ANR). My solution in Java would be to extend the BetterDialogs class to get an access to the AlertDialog, the ad object (via reflection because it is private). Easy for me but not for you if you're not familiar with Java. And as I said, I'm not convinced by your solution with a timer. That would be a strange user experience to see the keyboard opening and vanishing each time you enter the EditText.
Modal dialogs do not exist in Android and are a feature introduced by Erel in B4A. So they have some limits. This is not a problem if you consider that they're intended for simple forms. That's why I didn't even try to make my UltimateListView library work with them (the ULV can display items but the Click event is delayed and so unusable).

 

[MMORETTI964]

Maybe you should reconsider the former option because the big problem in your case is that you need to know the window that contains your EditText to hide the keyboard and this window cannot be known before calling CustomDialog(). Once the dialog is displayed, many events won't work because these messages are delayed by B4A (but not all or you would get an ANR). My solution in Java would be to extend the BetterDialogs class to get an access to the AlertDialog, the ad object (via reflection because it is private). Easy for me but not for you if you're not familiar with Java. And as I said, I'm not convinced by your solution with a timer. That would be a strange user experience to see the keyboard opening and vanishing each time you enter the EditText.
Modal dialogs do not exist in Android and are a feature introduced by Erel in B4A. So they have some limits. This is not a problem if you consider that they're intended for simple forms. That's why I didn't even try to make my UltimateListView library work with them (the ULV can display items but the Click event is delayed and so unusable).

Really I'm not so familiar with Java but I've worked a little with it (fixed/rearranged a java PDF library with B4A and made some BlackBerry support to programmers), so I should have a chance.
As now, I will reconvert to form (with timer, because I don't know how stop keyboard but having the cursor visible), when I'll have some time I will try it (and I will report to you).

Many thanks for your support.

 

[bluedude]

I use this but it seems it has a bug with input boxes. After the dialog is finished the keyboard cannot be hidden. I tried everything (hidekeyboard) but the keyboard stays visible.

I'm using version 1.4.

 

[Informatix]

I use this but it seems it has a bug with input boxes. After the dialog is finished the keyboard cannot be hidden. I tried everything (hidekeyboard) but the keyboard stays visible.

I'm using version 1.4.

How do you open the keyboard? Because in BD the dialog is opened and closed as it should, with the setSoftInputMode and hideSoftInputFromWindow methods. On my devices and on emulators, I have no issue.

 

[bluedude]

Hi,

I'm not doing anything specifically to open the keyboard, I just call a betterdialog. That's it.

I tested it in several activities but the keyboard stays opened. I deploy for Android 4.x and run it on 4.3.x and higher.

Maybe a conflict with other libraries? Cannot test that in detail because I use stuff like AHNavigationDrawer, AHViewPager and a few other custom UI elements.

Will test your demo project to see if I have the same problem.