Contextual help project

[jj2007]

1) Pass command line into the search box. Duh..
2) Activate the IEContainer

OK, give it a try ;-)

[mywan]

Near perfect  :t
I did forget 3)
3) Fix the <Win32.hlp>

That makes the the list:
1) Command line search.
2) <Win32.hlp>

Though mostly I'm not terribly worried about <Win32.hlp> at this point. You could just drop it without creating any significant inconvenience.

[jj2007]

I have added
\Masm32\help\xHelp\L_Command.exe
\Masm32\help\xHelp\L_string.exe
to the archive, for testing the launch via commandline. They use this simple source:

include \masm32\MasmBasic\MasmBasic.inc   ; download
   Init
   Launch "\Masm32\help\xHelp\xHelp.exe string array"
   Exit
end start

... but of course you could do the same from VB. Attention it's ANSI, not Unicode.
Once you see the new search string, you can use Return to display the first item, or TAB to move to the list; if the search is e.g. for CreateWindowEx, hit TAB, then < to see it right away in Win32.hlp

A propos: What's wrong with <Win32.hlp>? Works fine over here, as long as it is in \Masm32\help\WIN32.HLP ::)

[mywan]

Oh, the command line does work from a command prompt, but doesn't work if I try to put the command in a shortcut. Hence I never even knew it had a command line search option.

Wait: I put a space in the path so windows would let me quote the app path string and it started working and continued working after I removed the space. Very very weird. I'm going to experiment to figure out what's happening. As far as I can tell L_Command.exe and L_string.exe does nothing at all with or without an arg or whether xHelp is running or not.

Anyway, I'm going to configure my editor to use xHelp through F1 and see how it goes.

[mywan]

Apparently the command line issue was related to the "start in:" folder. If you have a path to execute like "\Desktop\xHelp\3107b\xHelp.exe blah" with a shortcut "start in:" path set to "\Desktop\xHelp\3107b\" with another xHelp in that "start in:" path then win 7 64 bit will execute that rather that the exe actually pointed to by the target string. Don't know about other systems. Well anyway...

I moved \xHelp under \masm where it was intended to be, and added this configuration string to my editor:
command.help.$(file.patterns.asm)=C:\masm32\help\xHelp\xHelp.exe $(CurrentWord)

This works perfectly, unless xHelp.exe is already running. If xHelp.exe is not running this runs xHelp.exe as hidden and it only show up in the task manager, and the fact that the editor never returned an exit code. So using my editor requires that Xhelp already be running. Apparently so long as Xhelp passes an arg it will never run a new instance. But xHelp running without an arg can run as many instances of xHelp as you want. A shortcut with args creates a new visible instance of xHelp fine, yet when executed from my editor it's hidden unless there was a preexisting instance of xHelp running. Almost certainly this is triggered by output redirection.

Code: [Select]

.if CL$() ; get the commandline
xchg eax, esi
.if Len(esi)>2
.if WinByTitle("Masm32 xHelp", 4)  ; we'll send a WM_COPYDATA message to
push eax ; arg for SetForegroundWindow
SendData eax, esi ; change the findbox in the current instance
call SetForegroundWindow
Exit
.endif
Let cLine=esi ; use to set hFind
.endif
.endif

[jj2007]

If you have a path to execute like "\Desktop"...

Is that desktop in the root??

This works perfectly, unless if xHelp.exe is already running - unless or if??.

Apparently so long as Xhelp passes an arg it will never run a new instance. But xHelp running without an arg can run as many instances of xHelp as you want.

That will be changed, it's bad behaviour indeed. Single instance is enough.
This part should have no problems with paths because it just sends a message:

Code: [Select]

.if CL$() ; get the commandline
xchg eax, esi
.if Len(esi)>2
.if WinByTitle("Masm32 xHelp", 4)  ; we'll send a WM_COPYDATA message to
push eax ; arg for SetForegroundWindow
SendData eax, esi ; change the findbox in the current instance
call SetForegroundWindow
Exit
.endif
Let cLine=esi ; use to set hFind
.endif
.endif
The only other potential problem with shortcuts is that xHelp.exe looks for IEContainer.exe in the current path. I could change that, though, by prepending the GetModulePathName, if you really need to launch it through a shortcut.

Edit: New version attached. It forces single instance and looks for IEContainer.exe in the same folder as xHelp.exe, e.g. \masm32\help\xHelp\xHelp.exe
In addition, if
- there is already an instance running
- a request for a string longer than 4 character with no spaces is sent
- no matches are found in the *.htm files
- and \masm32\help\xHelp\WIN32.HLP is present
then the string gets passed on directly to Win32 help.

[mywan]

If you have a path to execute like "\Desktop"...

Is that desktop in the root??

I do quiet often unzip to the desktop to try it out.

This works perfectly, unless if xHelp.exe is already running - unless or if??.

Apparently so long as Xhelp passes an arg it will never run a new instance. But xHelp running without an arg can run as many instances of xHelp as you want.

I did in fact mean unless, not if.
If xHelp is already running then when my editor executes:
command.help.$(file.patterns.asm)=C:\masm32\help\xHelp\xHelp.exe $(CurrentWord)
It works fine.
If xHelp is not already running then when my editor runs it in hidden mode. The window is invisible, but it is running. The code selection below is not about separate instances, it about the fact that my editor redirects standard out back to itself is likely the cause of the issue. Hence when ShowLbSel > "invoke ShowWindow, lastWin, SW_HIDE" it's not the window you think your hiding. In this case lastWin is the current window.

That will be changed, it's bad behaviour indeed. Single instance is enough.
This part should have no problems with paths because it just sends a message:

Code: [Select]

.if CL$() ; get the commandline
xchg eax, esi
.if Len(esi)>2
.if WinByTitle("Masm32 xHelp", 4)  ; we'll send a WM_COPYDATA message to
push eax ; arg for SetForegroundWindow
SendData eax, esi ; change the findbox in the current instance
call SetForegroundWindow
Exit
.endif
Let cLine=esi ; use to set hFind
.endif
.endif

You completely missed the point when you presumed I meant "if" when I said "unless".

The only other potential problem with shortcuts is that xHelp.exe looks for IEContainer.exe in the current path. I could change that, though, by prepending the GetModulePathName, if you really need to launch it through a shortcut.

No, don't change that. That works perfectly.

Edit: New version attached. It forces single instance and looks for IEContainer.exe in the same folder as xHelp.exe, e.g. \masm32\help\xHelp\xHelp.exe
In addition, if
- there is already an instance running
- a request for a string longer than 4 character with no spaces is sent
- no matches are found in the *.htm files
- and \masm32\help\xHelp\WIN32.HLP is present
then the string gets passed on directly to Win32 help.

My editor still runs the last version with SW_HIDE set is still absolutely consistent. If strings longer than 4 characters with no spaces are redirected for any reason you'll trash my capacity to use any of the notes I've been compiling. If that happens the app becomes nearly useless to me. I did download Win32.hlp to see what it was you intended. I was way off on what I thought you were trying to do with <Win32.hlp>. Last time I seen that help file was in win 95 days, and I only have limited use for it personally. Though it is still effectively relevant info the only bits of information I need is not the definitions it contains but rather it's proper usage (syntax) in MASM.

xHelp01Aug.zip fixed none of the issues.

[jj2007]

Sorry that it doesn't work for you. In any case, thanks for the really detailed and well elaborated feedback. You have helped me a lot :icon14:

Can anybody else give feedback? It seems mywan's setup is a bit unusual - how does a standard installation (XP, Win7) work with xHelp version 1 August posted above?

Thanks,
jj

[mywan]

Sorry that it doesn't work for you. In any case, thanks for the really detailed and well elaborated feedback. You have helped me a lot :icon14:

Can anybody else give feedback? It seems mywan's setup is a bit unusual - how does a standard installation (XP, Win7) work with xHelp version 1 August posted above?

Thanks,
jj

It doesn't take an unusual setup to reproduce the SW_HIDE bug. All it takes is run it with any program that pipes standard out from xHelp back to itself. Basically when run from any editor with an output pane. You can download a standalone SciTe setup and see it yourself. I can also write a quick program to demonstrate it if you wish.

[jj2007]

OK, I fixed one issue: xHelp.dat got a prepended path from GetModuleFileName, because when xHelp was launched from elsewhere, it couldn't find the settings in xHelp.dat - and that could indeed produce a half-hidden IE mini window in the upper left corner.

xHelp is tested with the MasmBasic editor (RichMasm), and there it works chained with the MasmBasic guide, i.e. it first tests if e.g. SendMessage is a MasmBasic command (it's not, of course), then passes the search string on to xHelp, which finds several matches in \masm32\help and, if the user wishes so, offers also Win32.hlp (still the best choice for many API calls because the SendMessage page pops right into your face). PostMessage would not have matches for \masm32\help\*.chm, so xHelp will show you directly the Win32.hlp page, except when launched the first time: then it displays the dialog, and you have to hit Return.

Re redirection, as said earlier it shouldn't be an issue because 1. why should an editor redirect the search string if none of the bloody M$ search products returns info on whether searching was successful and 2. xHelp does not use StdIn or StdOut, it's a plain Windows app.
 :icon14:

[mywan]

When I run xHelp from SciTe and get an invisible instance of xHelp running I ran the following script to show its state:

Code: [Select]

Dim $str
Dim $state=WinGetState("[CLASS:MB GUI]","")
If BitAND($state,1) Then
   $str="Exist: True"&@CRLF
Else
   $str="Exist: False"&@CRLF
EndIf
If BitAND($state,2) Then
   $str=$str&"Visible: True"&@CRLF
Else
   $str=$str&"Visible: False"&@CRLF
EndIf
If BitAND($state,4) Then
   $str=$str&"Enabled: True"&@CRLF
Else
   $str=$str&"Enabled: False"&@CRLF
EndIf
If BitAND($state,8) Then
   $str=$str&"Active: True"&@CRLF
Else
   $str=$str&"Active: False"&@CRLF
EndIf
If BitAND($state,16) Then
   $str=$str&"Minimized: True"&@CRLF
Else
   $str=$str&"Minimized: False"&@CRLF
EndIf
If BitAND($state,32) Then
   $str=$str&"Maximized: True"&@CRLF
Else
   $str=$str&"Maximized: False"&@CRLF
EndIf
MsgBox(0,"xHelp Window States:",$str)
That produces this message box:

[jj2007]

OK, I found the bugger when launching it via SciTex. Weird things may happen when launched from there, but when I inserted a ShowWindow SW_SHOW before entering the message loop, everything seems just fine.

By the way, the buggy version worked e.g. for PostMessage, i.e. for a search that triggered the Win32 hlp window and therefore didn't need the main xHelp dialog.

Attached the new one, source included.

Again, thanks for all your efforts, mywan :icon14:

[mywan]

Sorry, been a bit tied up lately. Yes, the issue is fixed. As far as I can tell atm there's nothing left to fix, except maybe a few nitpicks. Everything seems to be fully functional and working 

[jj2007]

Great :t

I have started a thread on how to use it in qEditor. If anybody likes to add howtos for other editors, that would be most welcome. It's already tied to the F1 key in MasmBasic's RichMasm editor.

[jj2007]

I added one new feature: While scrolling through the html files in the listbox, you can press + (plus, like in "more") to see the original chm file in HtmlHelp. If you need this feature, extract xHelp.exe from the MasmBasic archive.