Crash using HELP facilities

I have run into an intermittent error. I am running /CHECKMATE as I test the interfaces and coding.

I have incorporated HELP into my program, and am getting a crash message about the application running out of memory. It is occurring only when I click on my HELP menu item, and usually the third or fourth item clicked. That said, as a test, I opened HELP for 10 items, and didn't get a crash - thus the intermittent nature.

Looking at the task manager at the time of the crash, it indicates the program is consuming 864 MB. In my link step, my link options for memory are:

/heap:12000000,6000000 /stack:9600000,4800000

Since it is only when I invoke HELP that the error is occurring, only a couple of options come to mind. One is that when HELP is decompressing the file, it might attempt allocate a great deal of memory, and the error occurs. Or, as I am building the windows, I have a temporary on the stack that I have included in a winio@() statement that shouldn't be there. (I have to watch out for that one!). I have known this to sometimes cause an issue with concurrent windows getting hammered at run-time.

Any insights one may have will be most appreciated.

One other piece of information.

There seems to be an issue with the keyword sent to the HELP facility. For example, one of my keywords is 'INDIVIDUAL LOG STRIP'. This is a character constant supplied as an argument to the routine that builds the winio@() command to create the menu entry.

However, the string being processed by the HELP facility is:

INDIVIDUAL LOG STRIPOption Selected=Q/st/sc=range=

The 'extra' stuff are character constants used elsewhere in the program.

Some of the keywords work fine; this one did not.

Perhaps this kind of problem might be the cause of the crashes?

The text of the crash is preceded with a big red 'X' in a circle. Text reads:

There is not enough memory available for this task. Quit one or more programs to increase available memory, then try again.

The Task Manager shows I'm using only 32% of my 32gb.

I think this is an OS message, not ClearWin+.

Bill,

1. Are you using 32bit FTN95 not 64bit one?
2. Are you using mixed language programming?

Dan,

1. Yes, 32-bit.
2. Yes. Coordinate transformation/conversion, report generation (PDF creation) All are compiled using SCC.

Unasked:

1. Same problems occur with /CHECKMATE and /RELEASE.
2. Using /stack and /heap in the SLINK step can cause 'odd behaviors'. Thought it might be an issue.....

Insights?

1. if you started playing game with the devil (stack) and his wife (heap) you are done. Just dump effing 32bs forever. Use 32 just temporally for debugging unknown for 64bit compiler bug or if SDBG64 shows wrong line.

2. never use two compilers in the same program

I have incorporated HELP into my program

Can you expand on this statement?

The immediate ClearWin+ options are to use %ht or %wb. An alternative is to create a compiled html file (like ftn95.chm) and access it from your program.

Paul, sorry I was not clear.

I have both the %th as well as the callback form

i.e. winio@('%mn[Help[Help]]','HELP_LOOKUP',HELP_FILE,TOKEN)

I use HelpScribble to create the CHM file. After the compile of the help file, there are no errors listed.

The crash I get does not invoke the Salford traceback, either in /CHECKMATE or /RELEASE.

There are other symptoms that can occur when the help file is finally opened. But one step at a time!

All the problems are using the compiled .CHM file.

Is it possible to create a sample program and put a sample chm file on DropBox?

I'll see if I can get it to happen with a sample. When I was playing around to understand how it all worked, I did that, but only used a very small, extremely simple CHM file.

That said, will work on it and post the links here.

I have a sample prepared. It does not exhibit all the symptoms I've seen, but it does show some of the most puzzling.

The link to DropBox is: https://www.dropbox.com/s/mpyrw85wzdqpeik/HTMLHELPCHM.zip?dl=0

I have included the entire Plato project file as well. In the small program, I've included some additional comments about the keyword lookup and what the CHM file has for matches.

There are 5 menu callbacks. help1 will cause a dialog to be displayed that there are multiple topics available and ask that you choose one for display. This locks up, and I have to use the task manager to kill the program.

help2 will show bring up the help file, but the Index box will show the word 'verify' a bunch of spaces and an undefined character string.

help3 will show 'export verify ' and the character string.

help4 will show 'integrity export verify ' and the character string.

help5 will display the CHM file from its beginning.

The CHM file is still in process of being edited and built, but does compile with no errors from its source.

In this context the keyword strings must be null terminated. For example in your program...

verify//char(0)

Also strings containing spaces must be within quotes. For example in your program...

''Catalog Search File''//char(0)

According to the Microsoft documentation, a list of keyworks may be used provided they are separated by semi-colons.

Paul, this is awesome. I had stumbled onto the null-termination when I saw the multiple items problem, but was unaware of the quoting of a string with spaces.

One question: If the appending of the char(0) is done in a function/sub-routine, when does this 'bind'? Stated another way, does this new string need to remain in statically allocated memory (not on the stack)?

I'm still puzzled by the 'HELP_CONTENTS' lock-up.

More TBA, yes?

Well, some success. I walked down through the menu selections one at a time, and here are the results.

help 1: Using double quotes shows (in the Index field) the string enclosed in double-quotes.

help2: Index field tab still shows the first selection, the Search tab shows the word export (my last manual search).

help3: Index field tab still shows the first selection, the Search tab shows the word export.

help4: Index tab shows the word integrity, and the index item installation is selected.

help 5: Goes to the Content tab and selects the first entry.

While the help file was open, I tried to do a Search using the double quoted term (without the double quotes). It found multiple topics as I expected.

In my application, however, the results after making the double-quote change are still not useful. No matter what I do, the display of the help file locks up, and the task has to be killed.

I am letting the stack and heap default during the link step.

Thinking that there may be a memory allocation issue, I cut the size of a couple of dimensions by a factor of 10. This dropped the executable size (as reported by the Task Manager) from 884 MB to 336 MB.

Now, The help file loads. None of the images are displayed, but the text is there.

It also appears that the lookup token cannot be dynamically created; it must be statically allocated.

With the changes that I outlined, I don't get any 'lock ups' when running your sample.

I am not sure what you mean by 'dynamically created' but if you can provide an example then I might be able to comment.

I am wondering if you understand that C-MasterHelp.chm should also run independently. For example you can run it directly from Microsoft file Explorer by double clicking on it (the chm file). But the version that you provide in the download is not yet fully functional. You can run it and view the help contents etc. but when you select a topic, the topic is not displayed.

I would only attempt to access C-MasterHelp.chm from your Fortran program after getting it to work independently as a stand-alone 'application'. (Actually its not an executable but is compiled hypertext that presumably the OS passes to the same 'reader' that is used by Windows Explorer etc..)

Hi Paul,

With the changes, and the test program, I don't get any lock-ups either.

But, these same commands and syntax (i.e. trailing NULL) still crash/lock when used in my full program. It works better (but not 100% successfully) if I drastically reduce my program size (static arrays).

I will use the USE_URL@ subroutine to get the help file displayed, and then the user can find the appropriate section. Or, I might be able to use the HH.EXE program. Still working on that last one, but Microsoft made it really hard.

The 'dynamically' refers to the lookup token being passed as a character string. To this must be added a NULL, so if one just codes that in [//CHAR(0)], it is built on the stack (dynamically). That does not work. S, I have to create a static variable in that routine, and parse the token and add the NULL.

Bill

Bill

I have had another look at this but I have run out of time for now.

The following seems to work. I have also got it working with a simpler form but I am not sure that the simpler form is safe.

    character*260:: help_file='c-masterhelp.chm'
    character*24 verify,export,integrity,catalog
    verify = 'verify'//char(0)
    export = 'export'//char(0)
    integrity = 'integrity'//char(0)
    catalog = ''Catalog Search File''//char(0)
    i = winio@('%ww[independent,not_fixed_size]&')
    i = winio@('%ca@&','Main Caption goes here')
    i = winio@('%mn[help[help1 - catalog]]&','HELP_LOOKUP',help_file,catalog)
    I = WINIO@('%mn[[help2 - verify]]&',     'HELP_LOOKUP',help_file,verify)
    I = WINIO@('%mn[[help3 - export]]&',     'HELP_LOOKUP',help_file,export) 
    I = WINIO@('%mn[[help4 - integrity]]&',  'HELP_LOOKUP',help_file,integrity)
    i = winio@('%mn[[help5 - Full File]]&',  'HELP_CONTENTS',help_file)

Thanks, Paul, for the effort. Since I'm not a Windows expert, there is little more that I can do also.

I have not abandoned the CHM file, nor incorporation into my software. I will use 'use_url()' to open the help file for the user until I can get it to run in the same address space as my application.

I have some other things to try, but, like you, I have run out of time for this problem. Still thinking about it, though!

Bill