On Sun, Dec 9, 2012 at 10:06 AM, <amphitr...@ok.de> wrote:
> In a subdialog I'd like to set a default in an entry line. As it
> is an edit field I tried
>
> ::method initDialog
> self~newEdit(IDC_EDIT5)~setText("localhost")
>
> alas with no success, the entry line stays blank. In contrast a
> method called from within this subdialog containing as test
>
> self~newEdit(IDC_EDIT5)~setText("set in subdlg")
>
> works as expected.
This is due to a "feature" of ooDialog called automatic data
detection. An attempt to explain it is made in sections 3.14.1,
3.14.2, and 3.14.3 of the ooDialog documentation.
It is a feature from the original ooDialog implementation that I
personally don't care for. Mostly because it seems to be hard for
many people to understand. If you want to understand it, you will at
least need to read the documentation on it.
In the case of your program, one way to get it to work is to add this method:
::method initAutoDetection
self~noAutoDetection
to your dialog. The reason it did not work is that after you set the
edit control text to what you want in initDialog() the ooDialog
framework sets it back to the empty string. This only happens if
automatic data detection is on, which it is by default. The method
above turns it off.
> -- UPDATE
> Changing from RcDialog to UserDialog I found that I have to use
> attrName of createEdit(), setting that variable shows correctly
> the default value in the entry line. Remains how to get there with
> RcDialog.
You can get there in a RcDialog by doing the exact same thing. By
setting the data attribute of the edit control to the text you want.
A data attribute is automatically created for the edit control.
One of the many reasons I dislike data attributes / automatic data
detection is that it is very difficult to know or remember what the
data attribute name is going to be when it is created automatically.
It is explained as well as possible in section 3.14.2 Data Attribute
Names.
> Just to show my struggle (and some minor questions) I do not
> discard my primal append
> -- END UPDATE
>
> Looking for some advice in the manuals I found in 'Appendix C.
> Dialog Creation Methods' of 'ooDialog User Guide Version 4.2.0':
> "... the method invocations that the programmer must code and the
> methods [...] that the programmer must provide." _Must_ is
> stipulated twice.
>
> So I added a
>
> ::method init
> forward class (super) continue
You do not *have* to have an init() method. Especially if you don't
do anything in the init() method as you show above. I'll have to
review the User Guide, it shouldn't say that you *must* have an init()
method
> (defineDialog is optional when using RcDialog) what changed
> nothing observable.
There is no point in having a defineDialog() method in a RcDialog.
You can have one, that might maybe be of use in some advanced
applications, but in general there is no point in it.
> Wading through the examples I found .InputBox with an optional
> prevalue argument to initialize the entry line. But how may I
> cluster four to ten of such input boxes together with some other
> dialog elements?
The .InputBox is a stand alone dialog. The convenience dialog classes
like .InputBox, .SingleSelection, etc.. are only of use in the most
simplistic situations. You can not achieve what you want by using
them.
> What I try to do: a dialog window which offers to change two host
> names and corresponding port numbers (hence four input fields),
> optional the dotted IP address is shown, and as currently there is
> no special input field for that it I use normal ones. Well,
> restricting input to positive integers in the range of 0..255 or
> 49152...65535 respectively would be nice. Of cause I may use
> MultiInputBox() but imagine a dialog with a stack of 10 input
> lines for two IP addresses plus port numbers, it just looks not
> too pro.
I think your problem is solved by using:
::method initAutoDetection
self~noAutoDetection
or by using the data attribute to pre-set the text.
.MultiInputBox is another convenience function that will not give you
a professional look.
> BTW, is there somewhere a complement to the a. m. 'Appendix C.
> Dialog Creation Methods' but for the "closing" methods like
> leaving just for a quick and unambiguous overview - ah, no, maybe
> I only have to re-read chapter 3.10. 'Standard Event Handling
> Methods' 5 more times.
No about the appendix. And I believe you should only need to re-read
chapter 3.10 *one* more time. ;-)
--
Mark Miesfeld
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
