Welcome to our forums
I have added an alternative to the standard callback HELP_LOOKUP. The alternative which has the name HELPLOOKUP takes a character variable that does not need the terminating null.
This will be available in the next release of the DLLs.
I think that this resolves the issue as far as it concerns ClearWin+.
Thanks for your efforts, Paul.
An interesting factoid; HelpScribble will display the help file it is working on for you, but does so by running hh.exe with some command line processing of the file. I have yet to understand how they do this because the documentation I have on HH.EXE has yielded nothing of value (except how to decompile a CHM file). So, they run the help file in a separate address space.
I find that interesting.
Bill
Some of the problems I had with the test program were likely because the folder into which the Help File was placed was a mapped drive. And, you can't have a CHM file on a networked drive unless you undo the Microsoft Security in the registry. So there is that. I should have recognized this earlier.
As an FYI, my SW is run from a physical drive and the help file is also stored there, so I'm not running into that issue with my operational SW.
That said, there are still problems with the sample even when the file is on a regular drive. I get the same lock-ups, and the search does not yield the proper results.
Paul, thanks for the changes to the HELP function. Things are working better. Testing the code to implement the 'HELPLOOKUP' callback, I ran across a 'limitation' that you should be aware of. None of this may be anything you have control over.
In the build of the HELP file, if there are two or more occurrences of a keyword, then the help processing will stall and the calling program must be terminated with the Task Manager. If there is only one occurrence of the keyword, then everything appears to work with no crashes.
With two or more occurrences, HELP will display a dialog box that shows the Topic pages that contain the keyword. It is when this is displayed that the program hangs up, or displays an 'out of memory' dialog box then hangs up/crashes. This latter case is inconsistently occurring.
John, all your statements have value.
I do not have the ability to use a different OS. Windows 10 all around, I'm afraid. I do have Windows 10 Home on one.
In order to test whether HelpScribble is the culprit (certainly could be) I'd need a CHM file that had two topics with the same keywords built some other way. The problem is: How do you get the HHK file extracted from the CHM file? I think (do not know) that this might help.
I have written a pre-processor of the HelpScribble topic grid file to find all the occurrences of duplicated keywords. It is helping. It has found a couple of dupes. One thing that I do find interesting is the use of 'nested index', where you have a subject and a sub-subject. I still need to verify, but I believe that I will not get a crash if two different topics contain the same nested index.
It is nice to have 32 gb, but since I only deal with the 32-bit FORTRAN, we have that overall limitation to deal with. And, yes, my users have (typically) 8-16 GB of memory.
As far as the overall program size, I have since reduced it to around 435 MB. One set of data was vastly over-allocated, and a smaller size would still do nicely.
Right now, invoking the Help file only increases the memory usage by about 22 MB, so should not be a problem.
Bill
Paul, I ahad a question regarding the HELP facility. It would appear that when I click the menu item to invoke the search of the HELP file for a keyword, that window gets minimized. Is this its normal behavior?
Bill
Bill
I can't see anything in ClearWin+ for HELPLOOKUP that would cause the main window to minimise.
If you can provide a sample program then I could investigate further.
I spent some time trying various things that match my code to get this to occur. No luck. If I have time, I will work on this some more; for now, I declare defeat.
I have an alternative that I'm confident will work, but will not give the same level of integration into the programs.
Bill
I tried this on Windows 10 Home. The window shows the text, but no images. On Windows 10 Pro, it locks up.
Since this particular HELP file did not have two topics with the same keyword, I cannot verify that the lock-up would not occur there.
Good news is that my 'workaround' works. It is unsatisfying, but it does the job. It is HelpScribble specific. If anyone else needs this, PM me and I'll tell you what I had to do.
BTW, HelpScribble uses the Windows help compiler to create the CHM file. There may be some HelpScribble specific thing that is causing this behavior, but it would have to be undocumented both in HelpScribble and in Windows HHC.EXE.
Things are working. In /CHECKMATE, the help file will not properly display; with /RELEASE, everything appears to be working. So, another thread with an issue of memory management in /CHECKMATE seems to be born out.
https://forums.silverfrost.com/Forum/Topic/3820&highlight=
Things are coming together!
I noticed that you used ZEROISE and that may be relevant.
Thanks, Paul, for the suggestion. I'll experiment!
Paul, back on Jan 20 in this thread, I stated that a window was minimized when HELP was invoked. I have more information.
Usually, and I cannot figure why, the window from which HELP was invoked goes to the background and/or the main window of the program gets brought to the top. The HELP is displayed over the top of that. If I close the HELP window, the main window continues to be displayed. I have to search the taskbar for the proper window to be displayed. My windows are all created as [independent].
If I am down two or three windows, the situation appears to be that the window from which the HELP is invoked goes to the background and/or the previous window stays visible/foreground, but still overlaid by the HELP file (as expected).
I am using the HELP syntax of HELPLOOKUP, attached to a menu item. I do not have a simple example.
Thanks. I don't have any further ideas on this at the moment.
Bill,
In the .NET version, there is a subroutine vcBringToFront which is 'normally used to re-activate a modeless dialog'. I think that what you have to do is to bring the 'parent' to the front before closing your help window under program control, and that should make if more easily discoverable. I'm not sure if there is already a Clearwin+ function for this, but in MSDN there is a logical function BringWindowToTop which should do the trick. You feed it the Window Handle of the Window you want on top. I imagine that this has the potential to go completely mad if you give the function an incorrect handle!
There seems to me to be two paradigms in Windows programs, one of which is to have a lot of independent windows (my slide scanner software does this). Personally, I find this approach difficult to use, especially after I'd accidentally closed one of them and wanted it back. The other approach is to only let the user do one thing at a time. Sometimes this latter approach feels overconstrained and tediously pedestrian, but it does mean that the programmer doesn't have to worry about the sort of issue that you describe. The optimum is to have some of each, selected on the basis of how the program works.
As far as 'I cannot figure why' the answer probably lies in some obscure Windows rationale, probably hidden away somewhere in MSDN ! (and at a guess I'd say that somewhere there is probably a stack of window handles from which the display order is obtained, with the last in being the earliest displayed, but remember that is just a guess).
Eddie
Eddie, unfortunately, the invocation of the HELP file, once instantiated, is not under my control, nor is the closure of that window a detectable event. So, programmatically, I cannot sense the user has the HELP file open or is closing it. I might be able to utilize focus control, but I have to be careful since I can get a runaway train of open windows competing for focus.
The remainder of this message re: HELP and window visibility has been superseded.
The idea that it might be the '[independent]' nature of my windows that causes this behavior did occur to me. I removed the [independent] from my windows but, unfortunately, the effect remains. Since most other programs I use on a regular basis are MDI-style applications, it might be that this behavior is not generally observed. My windows structure might require an overhaul in any case.
I have found that even though they are declared independent (or not), subsequent windows that are created have an interesting effect. Namely, the buttons/control on the parent window appear to be working, but not the menu selections of those parent windows. I am not using %lw (except where there are windows that need to be be spawned and accessed separately).
It might be that the parent window is not automatically 'disabled'.
I found a mis-placed '[independent]' in a separate routine invalidating what I said previously.
If this %ww[independent] parameter is not used, then the window from which HELP was invoked appears directly below the HELP window, as I would have hoped.
Sorry for any confusion.
Bill, It's good that you are getting there. My ambitions are clearly less than yours, as I don't do MDI. Instead, I rely on multiple invocations of an SDI program, if any user has that mental agility(while I lack). I also just launch my CHM files through the HH.EXE program, and let the user search for the specifics they want, supplemented with some small dialogs that describe what mouse button clicks do, selected from the Help menu item as 'Mouse help' and also through a toolbar button. Eddie