News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Contextual help project

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

Previous topic - Next topic

mywan

Quote from: jj2007 on July 27, 2012, 06:20:49 PMOn a side note: To test this, I had to install Chrome. They trick you into making you believe that you absolutely must use/create a Google account to use Chrome. Well, I have one that I rarely used; when logging in, they tell me about "unusual activity discovered", and that I must absolutely give them my mobile number so that they can send access codes via SMS. Google, go to hell :icon_mrgreen:
Yes, like Michael said, Google is data mining in the extreme. Just so you know, when you installed Google's official version of Chrome as a courtesy it provided you with a unique installation ID. Now, even if you never go to a Google domain again with Chrome they can track you through their ads placed on most every web page on the internet. That's why I'm using Iron instead of Chrome. Chrome is open source, and Google merely makes some tracking changes for their official installation. Iron can also be run from a thumb drive, with no registry writes, temp files, cache, or anything else written to or used outside of that thumb drive. You don't even have to use an installer. Just do a search of "google" in your registry now, and uninstalling will not get rid of it or your unique installation ID.

Personally, one of my Drawer options on my quick launch is a Host file toggle. Almost every site I go to has little boxes with "Page not found" in it. Oh, another thing, tacking cookies are not deleted by deleting cookies these days, or stopped by turning cookies off. Google "super cookies" to see what I mean. Primarily culprits are flash and silverlight. And no, there are no browsers in which privacy settings has any effect on these zombie cookies whatsoever and the usual blog advice is about universally useless. I don't give a crap what they know about me but anybody that tries to follow me like they do and I'm calling the cops. I use entirely separate sandboxed browsers for Google, facebook, and other such services. These browsers then have wrappers that automatically toggle Host file configs and have their own sets of privacy plugins and such. Many companies are even using hardware/software profiles to fingerprint you without any cookies, super or otherwise. So my profile toggle actually randomizes a bunch of junk fonts to swap in and out, switches various plugins, such as pdf readers (I like SumatraPDF), on and off, and swaps out various user scripts and addons. I still need a better way to fake screen resolutions and certain software version numbers. I even use a UserJS to rewrite Google search results so Google can't see what I clicked. IE I (almost) never use anyway, except for com automated stuff and testing. Some of them probably have me uniquely profiled as a dozen different users.

_________
Have you considered command line switches for setting preferences? The entire switch could be a single string of boolean zeroes and ones, or larger single digit numbers if you have a multiple choice option. The list could include:
Close app on selection.
Close precious help file on page change.
Use help file reader?browser [0?1].
Always on top.
My preference, in order given, would probably go something like: 10001. My choice in help file readers is not limited to hh.exe.

jj2007


sinsi

OK, can't close the help window, no sysmenu, no right-click. The only way is to quit xhelp.
😎

mywan

Getting much much better  :icon_cool:
(Complete bug description below)

The search box merely minimizes to the taskbar when you hit escape, but the IEContainer closes. Closing the search box requires right clicking the taskbar item. A more serious issue is when you run xHelp and do a search and select something to generate xHelp.dat and LastFind.tmp and close the search box, then when you run the search again it refuses to maximize (show normal). You only see it on the task bar. Deleting xHelp.dat will make it show normal again, but when you select an item the IEcontainer has the smallest possible size. Too small to see any of the help file. When you hit escape again at this point the IEContainer appears to close, except when you check the task manager it is still running. Deleting both xHelp.dat and LastFind.tmp mostly fixes it temporarily. Usually the IEContainer still keeps coming up the smallest possible size though.

A second minor bug is that if you do a search which produces only 1 result, open the IEContainer for that item, then if you close that container (not the search box) you can't open the IEContainer again unless you search for something different. I remember why this it from a previous issue you fixed. Likely an issue that's not relevant anymore.

I could live with your general approach, with this new IEContainer system if it did one more feature. That would be embedding the search box on the left side of the IEContainer like the left navigation column of a webpage.

jj2007

Quote from: mywan on July 28, 2012, 10:17:07 PM
Getting much much better  :icon_cool:
(Complete bug description below)
...
I could live with your general approach, with this new IEContainer system if it did one more feature. That would be embedding the search box on the left side of the IEContainer like the left navigation column of a webpage.

Bugs are hopefully fixed, and I added the option to hit F4 for closing the browser window. Alt F4 from the xHelp window closes everything, and I added a check that prevents "iconic" sizes from being saved ;-)
Re embedding: That is a question of taste and of "real estate". Once you embed the listbox, you are sacrificing a whole column of the browser window. The current xHelp window can be kept very small and be moved to a corner where it does not obscure what the user needs to read.

Where do you guys usually keep your Win32.hlp file? As \masm32\help\Win32.hlp?

dedndave

i like it - it seems to be very fast
is there a reason why the windows do not have a close button, rather than using F4/Alt-F4 ?

jj2007

#36
Quote from: dedndave on July 29, 2012, 04:26:48 AM
i like it - it seems to be very fast
is there a reason why the windows do not have a close button, rather than using F4/Alt-F4 ?

Typical response time for searching the 800+ html files is about 5 ms on my slow Celeron :biggrin:
xHelp tries to give you good value for your typing. Example:

unicode  21 matches (exact word, case-sensitive)
unicodE  70 matches (case-insensitive search)

unic...unicod also yield 70 matches, because the algo switches to partial, case-insensitive matches.

The first version uses MasmBasic's "intellicase" option for Instr, where both Unicode and unicode are valid full-word matches.

Generally I use Escape for proggies that can either stay active, or cannot lose any precious data. You just hit one key in a convenient corner and no worries.
For the browser window, Escape is not a good choice because it stops loading a webpage; so F4 (close document) seems a good choice for closing the browser but keeping the process (the window remains hidden, and exits only when the xHelp dialog closes for good).

Version b, attached below, integrates Win32.hlp - see xHelpReadme.txt

There is also now an option to send a search string with WM_COPYDATA. AFAIK it can be done with a console app, too. I wanted to test it on qEditor, but there seems no easy way to assign a Fxx key to an executable :(

EDIT: Just in case somebody wants to add a sysmenu or close box: The June version of MasmBasic lacked a few functions used in xHelp. To assemble xHelp.asm (or, better, xHelp.asc using RichMasm), unzip the attachment of the first post of http://masm32.com/board/index.php?topic=94.0 to the root of your Masm32 drive with "use folder names". Details (SetGlobals, Enum) in reply #2.

mywan

I like it. Can't find any operational problems in the latest version that isn't primarily preference issues. It did figure out why it was saving the iconic size window while not saving the size changes I made. To get it to save the IEContainer size and position requires, after changing the size, selecting a page to display from the search box. Reselecting the previous selection does not work. If you close (Esc, Alt-F4, or right click) before selecting a differing item in the search box the new size/position never gets saved.

My Win32.hlp files are in the default \masm32\help\Win32.hlp. Some peoples are not. Regardless of where they are they will still need to be the same path you create the xHelp subdirectory in.

On other feature it needs is to pass the command line arg into the search box and searches it when opened. Then when I'm reading/writing source I can simply hit F1 to search the word I just typed or placed under my cursor. The word doesn't even have to be selected in my editor, it merely chooses the word nearest my caret. No copy/paste/typing required.

I can either live with every other preference or take the time learn/do my own modifications. As far as embedding the search box the minimal space it does take is less obtrusive embedded in the IEContainer where it doesn't overlap anything than when always on top on all the other apps I may have open. The general sparsity of the text in the xHelp htm/chm help files, and the minimal size of the search box, means it would be less obtrusive than the left side menu of the standard hh.exe display of the standard chm files. I would like to use this this regardless for now, as I have a few other things to develop and, being so noobish presently, I'm far slower and less productive than you atm.

mywan

I ran across another problem. Apparently it is impossible for me to copy any text off the htm files displayed in the IEContainer control.

jj2007

Quote from: mywan on July 29, 2012, 12:52:54 PM
I like it.
Thanks :biggrin:

QuoteTo get it to save the IEContainer size and position requires, after changing the size, selecting a page to display from the search box.
Fixed. It saves new size/position immediately now, unless you write-protect the *.dat file, of course ;-)

QuoteReselecting the previous selection does not work.
What do you mean?? Navigation inside the browser works fine for me... ::)

Quote
My Win32.hlp files are in the default \masm32\help\Win32.hlp. Some peoples are not. Regardless of where they are they will still need to be the same path you create the xHelp subdirectory in.
It is assumed that the user extracts the zip to [Masm32 drive]\, so that should work fine, no extra copy of Win32.hlp needed. Just test the current version attached below, you should see <Win32.hlp?> as last item of the listbox.

QuoteOn other feature it needs is to pass the command line arg into the search box and searches it when opened. Then when I'm reading/writing source I can simply hit F1
This is already foreseen. The snippet below works fine, but you can roll your own CreateProcess/WM_COPYDATA sequence, of course.

include \masm32\MasmBasic\MasmBasic.inc   ; download
  Init
  mov esi, CL$()   ; get the commandline for SendData
  or ebx, -1
  .Repeat
   .Break .if WinByTitle("Masm32 xHelp", 4)
   .if Zero?
      Launch "\masm32\help\xHelp\xHelp.exe"
      .Break .if !eax   ; !eax = CreateProcess failed
   .endif
   invoke Sleep, 10   ; 10*127 = 1 second for launching
   inc ebx
   xor eax, eax
  .Until ebx>127
  .if eax
   SendData eax, esi   ; use WM_COPYDATA to pass on the string
  .else
   MsgBox 0, Err$(), "Big problem:", MB_OK
  .endif
  Exit
end start

Quote from: mywan on July 29, 2012, 03:57:54 PM
I ran across another problem. Apparently it is impossible for me to copy any text off the htm files displayed in the IEContainer control.

That's right. Japheth's original release version of IEContainer.exe has the same problem.

mywan

Quote from: jj2007 on July 29, 2012, 05:04:17 PM
QuoteReselecting the previous selection does not work.
What do you mean?? Navigation inside the browser works fine for me... ::)

Not the browser, the search box selection. For instance: Enter a search term and select a page to display. Now hit ESC to close the browser. You now can't reopen the same page you just closed without opening a different page page. Sometimes requiring another search term altogether if there is only 1 instance of a given search term. It's not a major problem, but it's why I missed some of the details on a previous bug you've already fixed. In fact, IIRC, you only added this behavior because earlier, with standard browsers, selecting the same term twice would simply kill the browser altogether. This is no longer relevant with the IEContainer.

QuoteThat's right. Japheth's original release version of IEContainer.exe has the same problem.
I remember some things about these containers now. I had forgotten because I always used a new instance of IE itself for automation. You will have to listen for the copy event in WindProc and send the selected text to the clipboard yourself.

mywan

Adding the chm link was an excellent move. However, the implementation broke a bit. Not sure why since my ArgSpy says the arg string being passed is "C:\masm32\help\imdialog.chm". Including the quotes as strings, which shouldn't be the problem. In your NanoTimer function you test for the existence of "\Masm32\help\Win32.hlp". There is no Win32.hlp in my MASM help file folder or anywhere else. Perhaps that has something to do with it.

jj2007

Quote from: mywan on July 29, 2012, 05:29:49 PMEnter a search term and select a page to display. Now hit ESC to close the browser. You now can't reopen the same page you just closed without opening a different page page.

Fixed, I added a WM_LBUTTONDOWN handler to the listbox subclass proc:

SubList proc uses ebx hwnd:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
   SetGlobals
   .if uMsg==WM_CHAR
      .if wParam==VK_TAB
         invoke SendMessage, hFind, EM_SETSEL, 0, -1
         invoke SetFocus, hFind
      .endif
   .elseif uMsg==WM_LBUTTONDOWN
      .if lastWin
         .if !rv(IsWindowVisible, lastWin)
            invoke ShowWindow, lastWin, SW_RESTORE
         .endif
      .endif
   .endif
  invoke CallWindowProc, opSubList, hwnd, uMsg, wParam, lParam
  ret
SubList endp

mywan

Saving position is not quiet right either. It doesn't actually save the position until you hit Alt-F4 and close both the search box and the browser.

Do a search, open the browser via a selection and resize/move the browser. Hit Esc to close the browser (not the search box), then bring up the search box again and make another selection. The browser window get recreated at the original location forgetting the new position. Whatever position it has when you finally do close the search box (along with the browser) is the position it remembers.

mywan

Nice, 2 more issues and I will not have anything to complain about except preferences  :bgrin: