Hi Y'all,

The HLP files created with HelpScribble always stayed on top of my
application window.  But, with Win 7 and later we must use HTML (CHM)
help files.

HelpScribble creates these files very well and with no more trouble
than the HLP files.

BUT, the CHM windows are frequently hid behind other appllication
windows, including my application.  The help window can usually be
resurrected from the icon on the task bar.  However, this is not a
satisfactory solution for most users.

Anyone else experiencing this problem?  If so, do you have solution to
get the help window to always Stay on Top?

Thanks.

  >don<

Don,

>The HLP files created with HelpScribble always stayed on top of my
>application window. But, with Win 7 and later we must use HTML (CHM)
>help files.

I'm using Help&Manual to create my help files, as it was much easier to use 
and much more sophisticated than HelpScribble, when I evaluated them several
years ago. I haven't notice any issues with CHM files opening up behind 
other dialogs.

Both, Help&Manual and HelpScribble, use the MS HTML Help compiler to create
the CHM files, and CHM files are viewed using the MS HTML Help ActiveX 
control inside the MS HTML Help Viewer. The size, position, and some other 
details for the MS HTML Help Viewer -- including the Window State, like
minimized, maximized, or normalized -- can be controlled by the HTML Help 
ActiveX control through some settings in your CHM file.

Help&Manual allows you to control those settings, which are saved in the
HTML Help compiler's Project file, which has an .HHP extension. I don't know 
if you have the same editing feature in HelpScribble, but as both programs
use the MS HTML Help compiler, there must be an .HHP file somewhere.

You can also use the MS HTML Help Workshop to change those .HHP settings, 
if HelpScribble doesn't have those features. If you don't already have HTML 
Help Workshop installed, you can download it from here:

http://www.microsoft.com/en-us/download/details.aspx?id=21138

Another thing that might cause (HTML Help Viewer) dialogs to be created 
behind and hidden by other dialogs, could be that you call the Help with 
the wrong Dialog as Owner.

oHelp := XbpHelp():New():Create(oOwner, cHelpFile, cTitle)

You should use the active Dialog -- usually a top-level window -- as the
oOwner of the XbpHelp object. If you use "SetAppWindow()", or re-use the
same XbpHelp object without a valid oOwner, the HTML Help Viewer dialog
might open behind other dialogs. Basically, each top-level dialog should
have its own XbpHelp object and each XbpHelpLabel object should have the
associated XbpPart (or the XbpPart's Parent Dialog) as its owner.

Hope that helps.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
       Andreas.Gehrs-Pahl@InterAct911.com
       Andreas.Gehrs-Pahl@EJusticeSolutions.com
       Andreas@DDPSoftware.com
web:   http://www.Aerospace-History.net

Thanks Andreas,

The Help&Manual seems a little pricey.

But, you gave me some food for thought that may help me with
HelpScribble.

  >don<


On Fri, 14 Dec 2012 14:54:16 -0500, Andreas Gehrs-Pahl wrote:

>Don,
>
>>The HLP files created with HelpScribble always stayed on top of my
>>application window. But, with Win 7 and later we must use HTML (CHM)
>>help files.
>
>I'm using Help&Manual to create my help files, as it was much easier to use 
>and much more sophisticated than HelpScribble, when I evaluated them several
>years ago. I haven't notice any issues with CHM files opening up behind 
>other dialogs.
>
>Both, Help&Manual and HelpScribble, use the MS HTML Help compiler to create
>the CHM files, and CHM files are viewed using the MS HTML Help ActiveX 
>control inside the MS HTML Help Viewer. The size, position, and some other 
>details for the MS HTML Help Viewer -- including the Window State, like
>minimized, maximized, or normalized -- can be controlled by the HTML Help 
>ActiveX control through some settings in your CHM file.
>
>Help&Manual allows you to control those settings, which are saved in the
>HTML Help compiler's Project file, which has an .HHP extension. I don't know 
>if you have the same editing feature in HelpScribble, but as both programs
>use the MS HTML Help compiler, there must be an .HHP file somewhere.
>
>You can also use the MS HTML Help Workshop to change those .HHP settings, 
>if HelpScribble doesn't have those features. If you don't already have HTML 
>Help Workshop installed, you can download it from here:
>
>http://www.microsoft.com/en-us/download/details.aspx?id=21138
>
>Another thing that might cause (HTML Help Viewer) dialogs to be created 
>behind and hidden by other dialogs, could be that you call the Help with 
>the wrong Dialog as Owner.
>
>oHelp := XbpHelp():New():Create(oOwner, cHelpFile, cTitle)
>
>You should use the active Dialog -- usually a top-level window -- as the
>oOwner of the XbpHelp object. If you use "SetAppWindow()", or re-use the
>same XbpHelp object without a valid oOwner, the HTML Help Viewer dialog
>might open behind other dialogs. Basically, each top-level dialog should
>have its own XbpHelp object and each XbpHelpLabel object should have the
>associated XbpPart (or the XbpPart's Parent Dialog) as its owner.
>
>Hope that helps.
>
>Andreas

Donald Keating avait prétendu :
> Thanks Andreas,
>
> The Help&Manual seems a little pricey.
>
> But, you gave me some food for thought that may help me with
> HelpScribble.
>
>   >don<
>
>
> On Fri, 14 Dec 2012 14:54:16 -0500, Andreas Gehrs-Pahl wrote:
>
>> Don,
>> 
>>> The HLP files created with HelpScribble always stayed on top of my
>>> application window. But, with Win 7 and later we must use HTML (CHM)
>>> help files.
>> 
>> I'm using Help&Manual to create my help files, as it was much easier to use 
>> and much more sophisticated than HelpScribble, when I evaluated them several
>> years ago. I haven't notice any issues with CHM files opening up behind 
>> other dialogs.
>> 
>> Both, Help&Manual and HelpScribble, use the MS HTML Help compiler to create
>> the CHM files, and CHM files are viewed using the MS HTML Help ActiveX 
>> control inside the MS HTML Help Viewer. The size, position, and some other 
>> details for the MS HTML Help Viewer -- including the Window State, like
>> minimized, maximized, or normalized -- can be controlled by the HTML Help 
>> ActiveX control through some settings in your CHM file.
>> 
>> Help&Manual allows you to control those settings, which are saved in the
>> HTML Help compiler's Project file, which has an .HHP extension. I don't know 
>> if you have the same editing feature in HelpScribble, but as both programs
>> use the MS HTML Help compiler, there must be an .HHP file somewhere.
>> 
>> You can also use the MS HTML Help Workshop to change those .HHP settings, 
>> if HelpScribble doesn't have those features. If you don't already have HTML 
>> Help Workshop installed, you can download it from here:
>> 
>> http://www.microsoft.com/en-us/download/details.aspx?id=21138
>> 
>> Another thing that might cause (HTML Help Viewer) dialogs to be created 
>> behind and hidden by other dialogs, could be that you call the Help with 
>> the wrong Dialog as Owner.
>> 
>> oHelp := XbpHelp():New():Create(oOwner, cHelpFile, cTitle)
>> 
>> You should use the active Dialog -- usually a top-level window -- as the
>> oOwner of the XbpHelp object. If you use "SetAppWindow()", or re-use the
>> same XbpHelp object without a valid oOwner, the HTML Help Viewer dialog
>> might open behind other dialogs. Basically, each top-level dialog should
>> have its own XbpHelp object and each XbpHelpLabel object should have the
>> associated XbpPart (or the XbpPart's Parent Dialog) as its owner.
>> 
>> Hope that helps.
>> 
>> Andreas

Hi Don,

In HelpScribble, there is a "Windows editor" which has a "Stay on Top" 
checkbox.
Maybe this is the solution?

Best regards,
Raymond

On Sat, 15 Dec 2012 13:51:45 +0100, Raymond Fischbach wrote:

>Donald Keating avait prétendu :
>> Thanks Andreas,
>>
>> The Help&Manual seems a little pricey.
>>
>> But, you gave me some food for thought that may help me with
>> HelpScribble.
>>
>>   >don<
>>
>>
>> On Fri, 14 Dec 2012 14:54:16 -0500, Andreas Gehrs-Pahl wrote:
>>
>>> Don,
>>> 
>>>> The HLP files created with HelpScribble always stayed on top of my
>>>> application window. But, with Win 7 and later we must use HTML (CHM)
>>>> help files.
>>> 
>>> I'm using Help&Manual to create my help files, as it was much easier to use 
>>> and much more sophisticated than HelpScribble, when I evaluated them several
>>> years ago. I haven't notice any issues with CHM files opening up behind 
>>> other dialogs.
>>> 
>>> Both, Help&Manual and HelpScribble, use the MS HTML Help compiler to create
>>> the CHM files, and CHM files are viewed using the MS HTML Help ActiveX 
>>> control inside the MS HTML Help Viewer. The size, position, and some other 
>>> details for the MS HTML Help Viewer -- including the Window State, like
>>> minimized, maximized, or normalized -- can be controlled by the HTML Help 
>>> ActiveX control through some settings in your CHM file.
>>> 
>>> Help&Manual allows you to control those settings, which are saved in the
>>> HTML Help compiler's Project file, which has an .HHP extension. I don't know 
>>> if you have the same editing feature in HelpScribble, but as both programs
>>> use the MS HTML Help compiler, there must be an .HHP file somewhere.
>>> 
>>> You can also use the MS HTML Help Workshop to change those .HHP settings, 
>>> if HelpScribble doesn't have those features. If you don't already have HTML 
>>> Help Workshop installed, you can download it from here:
>>> 
>>> http://www.microsoft.com/en-us/download/details.aspx?id=21138
>>> 
>>> Another thing that might cause (HTML Help Viewer) dialogs to be created 
>>> behind and hidden by other dialogs, could be that you call the Help with 
>>> the wrong Dialog as Owner.
>>> 
>>> oHelp := XbpHelp():New():Create(oOwner, cHelpFile, cTitle)
>>> 
>>> You should use the active Dialog -- usually a top-level window -- as the
>>> oOwner of the XbpHelp object. If you use "SetAppWindow()", or re-use the
>>> same XbpHelp object without a valid oOwner, the HTML Help Viewer dialog
>>> might open behind other dialogs. Basically, each top-level dialog should
>>> have its own XbpHelp object and each XbpHelpLabel object should have the
>>> associated XbpPart (or the XbpPart's Parent Dialog) as its owner.
>>> 
>>> Hope that helps.
>>> 
>>> Andreas
>
>Hi Don,
>
>In HelpScribble, there is a "Windows editor" which has a "Stay on Top" 
>checkbox.
>Maybe this is the solution?
>
>Best regards,
>Raymond
>
Hi Raymond,

Good to hear from you.

As best I can determine the "Stay on Top" option is not available for
HTML help files.  Please see attachment.

  >don<

Dans son message précédent, Donald Keating a écrit :
> On Sat, 15 Dec 2012 13:51:45 +0100, Raymond Fischbach wrote:
>
>> Donald Keating avait prétendu :
>>> Thanks Andreas,
>>> 
>>> The Help&Manual seems a little pricey.
>>> 
>>> But, you gave me some food for thought that may help me with
>>> HelpScribble.
>>> 
>>>   >don<
>>> 
>>> 
>>> On Fri, 14 Dec 2012 14:54:16 -0500, Andreas Gehrs-Pahl wrote:
>>> 
>>>> Don,
>>>> 
>>>>> The HLP files created with HelpScribble always stayed on top of my
>>>>> application window. But, with Win 7 and later we must use HTML (CHM)
>>>>> help files.
>>>> 
>>>> I'm using Help&Manual to create my help files, as it was much easier to 
>>>> use  and much more sophisticated than HelpScribble, when I evaluated them 
>>>> several years ago. I haven't notice any issues with CHM files opening up 
>>>> behind  other dialogs.
>>>> 
>>>> Both, Help&Manual and HelpScribble, use the MS HTML Help compiler to 
>>>> create the CHM files, and CHM files are viewed using the MS HTML Help 
>>>> ActiveX  control inside the MS HTML Help Viewer. The size, position, and 
>>>> some other  details for the MS HTML Help Viewer -- including the Window 
>>>> State, like minimized, maximized, or normalized -- can be controlled by 
>>>> the HTML Help  ActiveX control through some settings in your CHM file.
>>>> 
>>>> Help&Manual allows you to control those settings, which are saved in the
>>>> HTML Help compiler's Project file, which has an .HHP extension. I don't 
>>>> know  if you have the same editing feature in HelpScribble, but as both 
>>>> programs use the MS HTML Help compiler, there must be an .HHP file 
>>>> somewhere.
>>>> 
>>>> You can also use the MS HTML Help Workshop to change those .HHP settings, 
>>>> if HelpScribble doesn't have those features. If you don't already have 
>>>> HTML  Help Workshop installed, you can download it from here:
>>>> 
>>>> http://www.microsoft.com/en-us/download/details.aspx?id=21138
>>>> 
>>>> Another thing that might cause (HTML Help Viewer) dialogs to be created 
>>>> behind and hidden by other dialogs, could be that you call the Help with 
>>>> the wrong Dialog as Owner.
>>>> 
>>>> oHelp := XbpHelp():New():Create(oOwner, cHelpFile, cTitle)
>>>> 
>>>> You should use the active Dialog -- usually a top-level window -- as the
>>>> oOwner of the XbpHelp object. If you use "SetAppWindow()", or re-use the
>>>> same XbpHelp object without a valid oOwner, the HTML Help Viewer dialog
>>>> might open behind other dialogs. Basically, each top-level dialog should
>>>> have its own XbpHelp object and each XbpHelpLabel object should have the
>>>> associated XbpPart (or the XbpPart's Parent Dialog) as its owner.
>>>> 
>>>> Hope that helps.
>>>> 
>>>> Andreas
>> 
>> Hi Don,
>> 
>> In HelpScribble, there is a "Windows editor" which has a "Stay on Top" 
>> checkbox.
>> Maybe this is the solution?
>> 
>> Best regards,
>> Raymond
>> 
> Hi Raymond,
>
> Good to hear from you.
>
> As best I can determine the "Stay on Top" option is not available for
> HTML help files.  Please see attachment.
>
>   >don<

Hello Don,

Sorry, you are right. As I compile for both, when I looked at it, it 
was set for winhelp instead of html help and this window is only 
accessible for winhelp.

Then, you can try what Clayton is recommending:

   *** use this for .chm help files
   tdHelpObj("myhelp.chm",AppDesktop())

Best regards,
Raymond

On Sat, 15 Dec 2012 15:49:28 +0100, Raymond Fischbach wrote:

>Dans son message précédent, Donald Keating a écrit :
>> On Sat, 15 Dec 2012 13:51:45 +0100, Raymond Fischbach wrote:
>>
>>> Donald Keating avait prétendu :
>>>> Thanks Andreas,
>>>> 
>>>> The Help&Manual seems a little pricey.
>>>> 
>>>> But, you gave me some food for thought that may help me with
>>>> HelpScribble.
>>>> 
>>>>   >don<
>>>> 
>>>> 
>>>> On Fri, 14 Dec 2012 14:54:16 -0500, Andreas Gehrs-Pahl wrote:
>>>> 
>>>>> Don,
>>>>> 
>>>>>> The HLP files created with HelpScribble always stayed on top of my
>>>>>> application window. But, with Win 7 and later we must use HTML (CHM)
>>>>>> help files.
>>>>> 
>>>>> I'm using Help&Manual to create my help files, as it was much easier to 
>>>>> use  and much more sophisticated than HelpScribble, when I evaluated them 
>>>>> several years ago. I haven't notice any issues with CHM files opening up 
>>>>> behind  other dialogs.
>>>>> 
>>>>> Both, Help&Manual and HelpScribble, use the MS HTML Help compiler to 
>>>>> create the CHM files, and CHM files are viewed using the MS HTML Help 
>>>>> ActiveX  control inside the MS HTML Help Viewer. The size, position, and 
>>>>> some other  details for the MS HTML Help Viewer -- including the Window 
>>>>> State, like minimized, maximized, or normalized -- can be controlled by 
>>>>> the HTML Help  ActiveX control through some settings in your CHM file.
>>>>> 
>>>>> Help&Manual allows you to control those settings, which are saved in the
>>>>> HTML Help compiler's Project file, which has an .HHP extension. I don't 
>>>>> know  if you have the same editing feature in HelpScribble, but as both 
>>>>> programs use the MS HTML Help compiler, there must be an .HHP file 
>>>>> somewhere.
>>>>> 
>>>>> You can also use the MS HTML Help Workshop to change those .HHP settings, 
>>>>> if HelpScribble doesn't have those features. If you don't already have 
>>>>> HTML  Help Workshop installed, you can download it from here:
>>>>> 
>>>>> http://www.microsoft.com/en-us/download/details.aspx?id=21138
>>>>> 
>>>>> Another thing that might cause (HTML Help Viewer) dialogs to be created 
>>>>> behind and hidden by other dialogs, could be that you call the Help with 
>>>>> the wrong Dialog as Owner.
>>>>> 
>>>>> oHelp := XbpHelp():New():Create(oOwner, cHelpFile, cTitle)
>>>>> 
>>>>> You should use the active Dialog -- usually a top-level window -- as the
>>>>> oOwner of the XbpHelp object. If you use "SetAppWindow()", or re-use the
>>>>> same XbpHelp object without a valid oOwner, the HTML Help Viewer dialog
>>>>> might open behind other dialogs. Basically, each top-level dialog should
>>>>> have its own XbpHelp object and each XbpHelpLabel object should have the
>>>>> associated XbpPart (or the XbpPart's Parent Dialog) as its owner.
>>>>> 
>>>>> Hope that helps.
>>>>> 
>>>>> Andreas
>>> 
>>> Hi Don,
>>> 
>>> In HelpScribble, there is a "Windows editor" which has a "Stay on Top" 
>>> checkbox.
>>> Maybe this is the solution?
>>> 
>>> Best regards,
>>> Raymond
>>> 
>> Hi Raymond,
>>
>> Good to hear from you.
>>
>> As best I can determine the "Stay on Top" option is not available for
>> HTML help files.  Please see attachment.
>>
>>   >don<
>
>Hello Don,
>
>Sorry, you are right. As I compile for both, when I looked at it, it 
>was set for winhelp instead of html help and this window is only 
>accessible for winhelp.
>
>Then, you can try what Clayton is recommending:
>
>   *** use this for .chm help files
>   tdHelpObj("myhelp.chm",AppDesktop())
>
>Best regards,
>Raymond
>
Yes, I've had it set that way since I started using HTML help files.
But, they still frequently hide behind other displayed windows.

Thanks for your thoughts.

   >don<

Don, Raymond,

>>Then, you can try what Clayton is recommending:

>>*** use this for .chm help files
>>tdHelpObj("myhelp.chm",AppDesktop())

I'm pretty sure that using this could cause the problem that you describe.

I don't have or use TopDown, but I assume that the "AppDesktop()" in the
"tdHelpObj()" function defines the Owner of the "XbpHelp()" object. If that
is the case, than this would explain why the HTML Help dialog would be shown
(randomly) behind other dialogs, as it uses the Desktop as the Owner.

Instead, create a new "XbpHelp()" object -- or update it with ":Configure()"
if you like -- to always have your top-level Dialog as the Owner, before you
assign it to an "XbpHelpLabel()" object or before using it directly.

The MS HTML Help Viewer requires a valid Window (Dialog) Handle, which the
Alaska Xbase++ runtime will determine from the "oOwner" of the "XbpHelp()" 
object. So, if you create separate Help Objects for each Dialog -- or even
for each "XbpHelpLabel()" -- with the correct Dialog (or XbasePart) as the 
Owner of the Help Objects -- or if you change the Owner of the Help Object
with ":Configure()" -- you shouldn't get those issues anymore.

Give it a try, and let us know if it fixes the issue.

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
       Andreas.Gehrs-Pahl@InterAct911.com
       Andreas.Gehrs-Pahl@EJusticeSolutions.com
       Andreas@DDPSoftware.com
web:   http://www.Aerospace-History.net

On Sat, 15 Dec 2012 16:37:57 -0500, Andreas Gehrs-Pahl wrote:

>Don, Raymond,
>
>>>Then, you can try what Clayton is recommending:
>
>>>*** use this for .chm help files
>>>tdHelpObj("myhelp.chm",AppDesktop())
>
>I'm pretty sure that using this could cause the problem that you describe.
>
>I don't have or use TopDown, but I assume that the "AppDesktop()" in the
>"tdHelpObj()" function defines the Owner of the "XbpHelp()" object. If that
>is the case, than this would explain why the HTML Help dialog would be shown
>(randomly) behind other dialogs, as it uses the Desktop as the Owner.
>
>Instead, create a new "XbpHelp()" object -- or update it with ":Configure()"
>if you like -- to always have your top-level Dialog as the Owner, before you
>assign it to an "XbpHelpLabel()" object or before using it directly.
>
>The MS HTML Help Viewer requires a valid Window (Dialog) Handle, which the
>Alaska Xbase++ runtime will determine from the "oOwner" of the "XbpHelp()" 
>object. So, if you create separate Help Objects for each Dialog -- or even
>for each "XbpHelpLabel()" -- with the correct Dialog (or XbasePart) as the 
>Owner of the Help Objects -- or if you change the Owner of the Help Object
>with ":Configure()" -- you shouldn't get those issues anymore.
>
>Give it a try, and let us know if it fixes the issue.
>
>Andreas

Hi Andreas,

The default for the tdhelpobj() second parameter is setappwindow() and
that always worked fine with HLP files.  When changing to CHM I
changed it to appdesktop() per instructions in TD User Guide.

But, since it seems to make matters worse I'm going back to the
default setappwindow() and live with the consequences until I learn
better.

Thanks again for sharing your time and knowledge!

  >don<

Donald Keating avait prétendu :
> On Sat, 15 Dec 2012 16:37:57 -0500, Andreas Gehrs-Pahl wrote:
>
>> Don, Raymond,
>> 
>>>> Then, you can try what Clayton is recommending:
>>>> *** use this for .chm help files
>>>> tdHelpObj("myhelp.chm",AppDesktop())
>> 
>> I'm pretty sure that using this could cause the problem that you describe.
>> 
>> I don't have or use TopDown, but I assume that the "AppDesktop()" in the
>> "tdHelpObj()" function defines the Owner of the "XbpHelp()" object. If that
>> is the case, than this would explain why the HTML Help dialog would be shown
>> (randomly) behind other dialogs, as it uses the Desktop as the Owner.
>> 
>> Instead, create a new "XbpHelp()" object -- or update it with ":Configure()"
>> if you like -- to always have your top-level Dialog as the Owner, before you
>> assign it to an "XbpHelpLabel()" object or before using it directly.
>> 
>> The MS HTML Help Viewer requires a valid Window (Dialog) Handle, which the
>> Alaska Xbase++ runtime will determine from the "oOwner" of the "XbpHelp()" 
>> object. So, if you create separate Help Objects for each Dialog -- or even
>> for each "XbpHelpLabel()" -- with the correct Dialog (or XbasePart) as the 
>> Owner of the Help Objects -- or if you change the Owner of the Help Object
>> with ":Configure()" -- you shouldn't get those issues anymore.
>> 
>> Give it a try, and let us know if it fixes the issue.
>> 
>> Andreas
>
> Hi Andreas,
>
> The default for the tdhelpobj() second parameter is setappwindow() and
> that always worked fine with HLP files.  When changing to CHM I
> changed it to appdesktop() per instructions in TD User Guide.
>
> But, since it seems to make matters worse I'm going back to the
> default setappwindow() and live with the consequences until I learn
> better.
>
> Thanks again for sharing your time and knowledge!
>
>   >don<

Hi Andreas and Don,

Following Andreas advices, I found out how to solve the problem, see 
the attached small txt file with how to do it using topdown.

I tried it and it works with .chm help files. I didn't tested it with 
.hlp files but I guess that it will also work.

Thanks Andreas for the tip.
Raymond

On Mon, 17 Dec 2012 11:46:26 +0100, Raymond Fischbach wrote:

>Donald Keating avait prétendu :
>> On Sat, 15 Dec 2012 16:37:57 -0500, Andreas Gehrs-Pahl wrote:
>>
>>> Don, Raymond,
>>> 
>>>>> Then, you can try what Clayton is recommending:
>>>>> *** use this for .chm help files
>>>>> tdHelpObj("myhelp.chm",AppDesktop())
>>> 
>>> I'm pretty sure that using this could cause the problem that you describe.
>>> 
>>> I don't have or use TopDown, but I assume that the "AppDesktop()" in the
>>> "tdHelpObj()" function defines the Owner of the "XbpHelp()" object. If that
>>> is the case, than this would explain why the HTML Help dialog would be shown
>>> (randomly) behind other dialogs, as it uses the Desktop as the Owner.
>>> 
>>> Instead, create a new "XbpHelp()" object -- or update it with ":Configure()"
>>> if you like -- to always have your top-level Dialog as the Owner, before you
>>> assign it to an "XbpHelpLabel()" object or before using it directly.
>>> 
>>> The MS HTML Help Viewer requires a valid Window (Dialog) Handle, which the
>>> Alaska Xbase++ runtime will determine from the "oOwner" of the "XbpHelp()" 
>>> object. So, if you create separate Help Objects for each Dialog -- or even
>>> for each "XbpHelpLabel()" -- with the correct Dialog (or XbasePart) as the 
>>> Owner of the Help Objects -- or if you change the Owner of the Help Object
>>> with ":Configure()" -- you shouldn't get those issues anymore.
>>> 
>>> Give it a try, and let us know if it fixes the issue.
>>> 
>>> Andreas
>>
>> Hi Andreas,
>>
>> The default for the tdhelpobj() second parameter is setappwindow() and
>> that always worked fine with HLP files.  When changing to CHM I
>> changed it to appdesktop() per instructions in TD User Guide.
>>
>> But, since it seems to make matters worse I'm going back to the
>> default setappwindow() and live with the consequences until I learn
>> better.
>>
>> Thanks again for sharing your time and knowledge!
>>
>>   >don<
>
>Hi Andreas and Don,
>
>Following Andreas advices, I found out how to solve the problem, see 
>the attached small txt file with how to do it using topdown.
>
>I tried it and it works with .chm help files. I didn't tested it with 
>.hlp files but I guess that it will also work.
>
>Thanks Andreas for the tip.
>Raymond

Thanks Raymond, makes sense, I'll try it and let you know.  It may
take me awhile as the two applications I've had trouble with each have
many dialogs.

Thanks Andreas for starting the juices flowing.

  >don<