fs->oc: cannot reproduce ...

As a preface, please let me say that the bug description here is somewhat ...
sparse. Besides that "run the test ..." is at least difficult to do for
non-QA-automation people (whyt not at least giving the path to the test file,
not to mention the link to the testtool documentation. Oh, well, we don't have
one ... so then ...): "There will be a warning" is a "bug description" which
usually leads me to simply putting a "needmoreinfo" keyword into the bug,
without doing anything else!

Okay, I managed to start the testtool, I found the test file, I successfully ran
it. The only warning I get is in tIBIS111158, saying "The control seems to be
not named in the document?! Verify!". Looking into the source of this test
method, I assume that I *should* have seen the message "'HID:123456' has not
been accepted as 'Help URL' value.".

Alas, I didn't this warning, or any other one except the one mentioned above.
This was on unxsols4.pro, with testtool9, and DEV300.m47

resolving WORKSFORME

As explained by Oliver, the cited warning indeed points to the problem, in a
very indirect way. Since I didn't understand this indirection, yet :), I
modified the testtool script to re-open the property browser after setting the
help ID, and to check it has been set correctly - in fact, this check fails, the
property is empty.

Re-opening issue.

grabbing

fs->oc: back to you: The code for entering the HelpURL is as follows:
  Kontext "TabGeneralControl"
  '/// Enter in 'Help URL' as value exactly 'HID:123456'
  TabGeneralControl.TypeKeys "<TAB>" , true        
  HelpURL.setText "HID:123456"
  TabGeneralControl.TypeKeys "<RETURN>",true
That is, you focus the "General" tab page, press TAB once (so the first control
on that page is focused), then enter some text in the HelpURL field (which does
not have the focus at that time), and then press RETURN in the General page.
Unfortunately, this RETURN doesn't arrive at the HelpURL control, since it does
not have the focus. So, the control has no chance of committing its content.

Why this works on the other platforms is beyond me - I suppose that's by
accident only.

Several possibilities come to my mind how to fix that:
- do
    HelpURL.TypeKeys "<RETURN>",true
  instead of 
    TabGeneralControl.TypeKeys "<RETURN>",true
  Then, the RETURN, which commits the content, is sent to the HelpURL
  control. This is what I tried, and it works fine.
  Disadvantage: It's still not really a simulation of what users do, since
  HelpURL does not have the focus at that time.
  (Except ... if the "true" parameter at the "TypeKeys" method has the
  semantics of "focus the control before typing keys" - in this case, your
  original code is correct, and it's a testtool bug of not actually focusing
  the control.)
- Do a
    Kontext "HelpURL"
  before typing the RETURN. In my understanding (which is pretty limited with
  respect to testtool scripts), this could also fix the issue.
- Use the proper number of TAB keys to travel to the HelpURL control, instead
  of doing only one TAB.

> (Except ... if the "true" parameter at the "TypeKeys" method has the
> semantics of "focus the control before typing keys" - in this case, your
> original code is correct, and it's a testtool bug of not actually focusing
> the control.)

Uhm, forget this. If the second parameter means "set the focus to this window"
(and according to the TypeKeys documentation, this indeed is the meaning), then
your script is *not* correct, since it then requests to set the focus to the
"General" tab page, not to the HelpURL. So, I indeed think typing the RETURN
into the HelpURL control instead of the TabGeneralControl is the right solution
here.

not a showstopper for 3.2 => 3.x