Hi Y'all,

Since switching to HTML (chm) for my help files I'm experiencing an
annoyance that I'd like to avoid.  When context sensitive help is called by
pressing an on screen help button or pressing the F1 key the help window is
often hidden behind the application window.  It can be brought into view by
clicking the icon in the taskbar but, that shouldn't be necessary.  And, is
a little difficult explaining to users.

My investigation to date reveals it happens most often with tddlg() windows
and not tddedlg().

My help files are created using Helpscribble.  For years using Windows help
(HLP) files they worked flawlessly.  Except when I made coding errors. 

Any and all suggestions will be greatly appreciated!

>don<

Since the problem seems to be (according to your statement) within 
tddlg() windows - I would suggest that you contact CJ.

Personally I've not seen this problem but I don't use TD.  All my apps 
are straight Xbase++.  I did use TD for a while and I learned a lot from 
CJ - I just migrated away from TD because I found the straight x/y 
cartesian coordinates better for my purposes.


On 4/9/2012 9:14 AM, Donald Keating wrote:
> Hi Y'all,
>
> Since switching to HTML (chm) for my help files I'm experiencing an
> annoyance that I'd like to avoid.  When context sensitive help is called by
> pressing an on screen help button or pressing the F1 key the help window is
> often hidden behind the application window.  It can be brought into view by
> clicking the icon in the taskbar but, that shouldn't be necessary.  And, is
> a little difficult explaining to users.
>
> My investigation to date reveals it happens most often with tddlg() windows
> and not tddedlg().
>
> My help files are created using Helpscribble.  For years using Windows help
> (HLP) files they worked flawlessly.  Except when I made coding errors. 
>
> Any and all suggestions will be greatly appreciated!
>
>> don<

Thanks Joe,

I'm not 100% pointing the finger at tddlg(), that's just my initial
investigation gut feeling.

Hoping someone else has had similar problem and will share their solution.
Or, someone has some ideas for me to explore that i've not thought of.

>don<

On Mon, 09 Apr 2012 14:37:27 -0700, Joe Carrick wrote:

> Since the problem seems to be (according to your statement) within 
> tddlg() windows - I would suggest that you contact CJ.
> 
> Personally I've not seen this problem but I don't use TD.  All my apps 
> are straight Xbase++.  I did use TD for a while and I learned a lot from 
> CJ - I just migrated away from TD because I found the straight x/y 
> cartesian coordinates better for my purposes.
> 
> 
> On 4/9/2012 9:14 AM, Donald Keating wrote:
>> Hi Y'all,
>>
>> Since switching to HTML (chm) for my help files I'm experiencing an
>> annoyance that I'd like to avoid.  When context sensitive help is called by
>> pressing an on screen help button or pressing the F1 key the help window is
>> often hidden behind the application window.  It can be brought into view by
>> clicking the icon in the taskbar but, that shouldn't be necessary.  And, is
>> a little difficult explaining to users.
>>
>> My investigation to date reveals it happens most often with tddlg() windows
>> and not tddedlg().
>>
>> My help files are created using Helpscribble.  For years using Windows help
>> (HLP) files they worked flawlessly.  Except when I made coding errors. 
>>
>> Any and all suggestions will be greatly appreciated!
>>
>>> don<

Donald,

I use TD and have moved from using Helpscribble to now using Help and 
Manual.  I do not have this issue and H&M can directly import 
helpscribble files.  Lots of added benefits to using H&M such as 
generation of html and pdf documentation directly from help source.

HTH.

Best regards,

Bruce


On 09/04/2012 22:47, Donald Keating wrote:
> Thanks Joe,
>
> I'm not 100% pointing the finger at tddlg(), that's just my initial
> investigation gut feeling.
>
> Hoping someone else has had similar problem and will share their solution.
> Or, someone has some ideas for me to explore that i've not thought of.
>
>> don<
>
> On Mon, 09 Apr 2012 14:37:27 -0700, Joe Carrick wrote:
>
>> Since the problem seems to be (according to your statement) within
>> tddlg() windows - I would suggest that you contact CJ.
>>
>> Personally I've not seen this problem but I don't use TD.  All my apps
>> are straight Xbase++.  I did use TD for a while and I learned a lot from
>> CJ - I just migrated away from TD because I found the straight x/y
>> cartesian coordinates better for my purposes.
>>
>>
>> On 4/9/2012 9:14 AM, Donald Keating wrote:
>>> Hi Y'all,
>>>
>>> Since switching to HTML (chm) for my help files I'm experiencing an
>>> annoyance that I'd like to avoid.  When context sensitive help is called by
>>> pressing an on screen help button or pressing the F1 key the help window is
>>> often hidden behind the application window.  It can be brought into view by
>>> clicking the icon in the taskbar but, that shouldn't be necessary.  And, is
>>> a little difficult explaining to users.
>>>
>>> My investigation to date reveals it happens most often with tddlg() windows
>>> and not tddedlg().
>>>
>>> My help files are created using Helpscribble.  For years using Windows help
>>> (HLP) files they worked flawlessly.  Except when I made coding errors. 
>>>
>>> Any and all suggestions will be greatly appreciated!
>>>
>>>> don<

Hi Bruce,

Thanks for the suggestion.

Installed H&M, recompiled my help file and it does same as the Helpscribble
file.

  >don<

On Sun, 15 Apr 2012 11:40:37 +0100, Bruce Carroll wrote:

> Donald,
> 
> I use TD and have moved from using Helpscribble to now using Help and 
> Manual.  I do not have this issue and H&M can directly import 
> helpscribble files.  Lots of added benefits to using H&M such as 
> generation of html and pdf documentation directly from help source.
> 
> HTH.
> 
> Best regards,
> 
> Bruce
> 
> 
> On 09/04/2012 22:47, Donald Keating wrote:
>> Thanks Joe,
>>
>> I'm not 100% pointing the finger at tddlg(), that's just my initial
>> investigation gut feeling.
>>
>> Hoping someone else has had similar problem and will share their solution.
>> Or, someone has some ideas for me to explore that i've not thought of.
>>
>>> don<
>>
>> On Mon, 09 Apr 2012 14:37:27 -0700, Joe Carrick wrote:
>>
>>> Since the problem seems to be (according to your statement) within
>>> tddlg() windows - I would suggest that you contact CJ.
>>>
>>> Personally I've not seen this problem but I don't use TD.  All my apps
>>> are straight Xbase++.  I did use TD for a while and I learned a lot from
>>> CJ - I just migrated away from TD because I found the straight x/y
>>> cartesian coordinates better for my purposes.
>>>
>>>
>>> On 4/9/2012 9:14 AM, Donald Keating wrote:
>>>> Hi Y'all,
>>>>
>>>> Since switching to HTML (chm) for my help files I'm experiencing an
>>>> annoyance that I'd like to avoid.  When context sensitive help is called by
>>>> pressing an on screen help button or pressing the F1 key the help window is
>>>> often hidden behind the application window.  It can be brought into view by
>>>> clicking the icon in the taskbar but, that shouldn't be necessary.  And, is
>>>> a little difficult explaining to users.
>>>>
>>>> My investigation to date reveals it happens most often with tddlg() windows
>>>> and not tddedlg().
>>>>
>>>> My help files are created using Helpscribble.  For years using Windows help
>>>> (HLP) files they worked flawlessly.  Except when I made coding errors. 
>>>>
>>>> Any and all suggestions will be greatly appreciated!
>>>>
>>>>> don<

Hello Don,

tdcDlg is the base TD dialog class.  It's a subclass of XbpDialog, so
nothing special about it.  It is used by all TD routines that open a
window.  It can be configured as a Top-Level, Child, Modal or
Step-Child.  I don't know if the window type is a factor, but just
saying tdDlg() is used doesn't provide much information.

tdcDEwindow is a subclass of tdcDlg, so it's also derived from
XbpDialog.  It's almost always a Child window.  Again, there is
nothing special about these classes.  They are just XbpDialog with
added ivars and methods.

Determining whether the window type is a factor is the first question
I'd want to answer.  Also, whether any disabled windows (such as in a
stream with the layered siblings technique) are involved.

As for chm help files, I've been using them for a couple of years at
least, and have not experienced anything like what you describe.  How
are you calling it up from within your app?


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement
 Spell-X  Spell Checking for Xbase++

Hi Clayton,

Thanks.

I didn't intend to point the finger at TD, tddlg() or tddedlg().  It was
just my initial observation that it appeared to be happening more from
tddlg() windows than tddedlg().  I've since determined that isn't
necessarily so.

I was primarily asking if anyone else had the problem.  It seems not so,
I'm still looking at my code.  It has been updated several times through
several versions of TD and I suspect I failed to heed your update
instructions for one or more of those updates.

  >don<

On Fri, 20 Apr 2012 04:29:31 -0400, Clayton Jones wrote:

> Hello Don,
> 
> tdcDlg is the base TD dialog class.  It's a subclass of XbpDialog, so
> nothing special about it.  It is used by all TD routines that open a
> window.  It can be configured as a Top-Level, Child, Modal or
> Step-Child.  I don't know if the window type is a factor, but just
> saying tdDlg() is used doesn't provide much information.
> 
> tdcDEwindow is a subclass of tdcDlg, so it's also derived from
> XbpDialog.  It's almost always a Child window.  Again, there is
> nothing special about these classes.  They are just XbpDialog with
> added ivars and methods.
> 
> Determining whether the window type is a factor is the first question
> I'd want to answer.  Also, whether any disabled windows (such as in a
> stream with the layered siblings technique) are involved.
> 
> As for chm help files, I've been using them for a couple of years at
> least, and have not experienced anything like what you describe.  How
> are you calling it up from within your app?
> 
> 
> Regards,
> Clayton
> 
> Clayton Jones   www.cjcom.net 
>  Top-Down Library for Xbase++
>  X-DBU Database Utility   
>  X-MEMO Memo Field Replacement
>  Spell-X  Spell Checking for Xbase++

Mmmmm....  it sounds as if you have some activity on the main screen 
from where you launch the help screen and this is switching back to that 
screen.  I have this on one of my screens but as I know that this is the 
cause it is not a 'problem'.

Best regards,

Bruce


On 17/04/2012 00:47, Donald Keating wrote:
> Hi Bruce,
>
> Thanks for the suggestion.
>
> Installed H&M, recompiled my help file and it does same as the Helpscribble
> file.
>
>    >don<
>
> On Sun, 15 Apr 2012 11:40:37 +0100, Bruce Carroll wrote:
>
>> Donald,
>>
>> I use TD and have moved from using Helpscribble to now using Help and
>> Manual.  I do not have this issue and H&M can directly import
>> helpscribble files.  Lots of added benefits to using H&M such as
>> generation of html and pdf documentation directly from help source.
>>
>> HTH.
>>
>> Best regards,
>>
>> Bruce
>>
>>
>> On 09/04/2012 22:47, Donald Keating wrote:
>>> Thanks Joe,
>>>
>>> I'm not 100% pointing the finger at tddlg(), that's just my initial
>>> investigation gut feeling.
>>>
>>> Hoping someone else has had similar problem and will share their solution.
>>> Or, someone has some ideas for me to explore that i've not thought of.
>>>
>>>> don<
>>>
>>> On Mon, 09 Apr 2012 14:37:27 -0700, Joe Carrick wrote:
>>>
>>>> Since the problem seems to be (according to your statement) within
>>>> tddlg() windows - I would suggest that you contact CJ.
>>>>
>>>> Personally I've not seen this problem but I don't use TD.  All my apps
>>>> are straight Xbase++.  I did use TD for a while and I learned a lot from
>>>> CJ - I just migrated away from TD because I found the straight x/y
>>>> cartesian coordinates better for my purposes.
>>>>
>>>>
>>>> On 4/9/2012 9:14 AM, Donald Keating wrote:
>>>>> Hi Y'all,
>>>>>
>>>>> Since switching to HTML (chm) for my help files I'm experiencing an
>>>>> annoyance that I'd like to avoid.  When context sensitive help is called by
>>>>> pressing an on screen help button or pressing the F1 key the help window is
>>>>> often hidden behind the application window.  It can be brought into view by
>>>>> clicking the icon in the taskbar but, that shouldn't be necessary.  And, is
>>>>> a little difficult explaining to users.
>>>>>
>>>>> My investigation to date reveals it happens most often with tddlg() windows
>>>>> and not tddedlg().
>>>>>
>>>>> My help files are created using Helpscribble.  For years using Windows help
>>>>> (HLP) files they worked flawlessly.  Except when I made coding errors. 
>>>>>
>>>>> Any and all suggestions will be greatly appreciated!
>>>>>
>>>>>> don<