News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Contextual help project

Started by mywan, July 18, 2012, 07:31:02 AM

Previous topic - Next topic

jj2007

Quote from: mywan on July 31, 2012, 11:20:55 AM
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

#77
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.

.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

#80
Quote from: mywan on August 01, 2012, 01:23:18 PMIf you have a path to execute like "\Desktop"...
Is that desktop in the root??

QuoteThis 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:

.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

Quote from: jj2007 on August 01, 2012, 06:07:42 PM
Quote from: mywan on August 01, 2012, 01:23:18 PMIf 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.

QuoteThis works perfectly, unless if xHelp.exe is already running - unless or if??.
QuoteApparently 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.

QuoteThat 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:
.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".

QuoteThe 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.


QuoteEdit: 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

Quote from: jj2007 on August 02, 2012, 01:34:57 AM
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:

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  :eusa_clap:

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.