Re: MidiStreaming problem/conflict with HTML Help
- From: MM <kylix_is@xxxxxxxxxxx>
- Date: Sat, 17 Oct 2009 13:06:27 +0100
On Sat, 17 Oct 2009 03:46:38 +0200, "Schmidt" <sss@xxxxxxxxx> wrote:
"MM" <kylix_is@xxxxxxxxxxx> schrieb im Newsbeitrag
news:2d9hd5lvi1a2t7rqjlvahv87heb4uf2fl0@xxxxxxxxxx
[HTML-Help-problems in conjunction with ThreadClasses]
Your hanging HTML-Help-search is caused by a
"not-responding thread-messagequeue" of your
workerthread (whatever the HTML-Help-instance is
trying to ask that windowless workerthread ... I have no clue).
Easy to fix, since you just need to place a DoEvents-call
in your ThreadClass' Main-Loop (just before the Sleep 1 call).
Other than that - the web is full with slight problems, related to
the HTML-Help-API - and I've just tested your Demo
you've put online some time ago (the opensource version
of your "KnowTheNotes"-App) with regards to HTML-
Help-Integration and yes - there are also other problems,
especially in the IDE - on shutdown (but not in the compiled
exe, at least in my tests).
To workaround that, I've put the HTML-API call Declaration
into a separately compiled ActiveX-Dll-Binary and used
that within your Main-App. No problems in this case,
neither in the IDE nor in the compiled Exe.
To not introduce a separate Dll-Binary, I've just placed this
code within the already existing "MidiStreaming.dll" in
a separate Class, called cHelpStarter, which is Public
as well as the other class (cThreadedPlayback), but
not instantiated in a threaded context.
The Object-instance of this (globally defined in a *.bas)
small Helper-Class is living as long as the App lives,
and cleans up automatically then, in case the App
enters its teardown.
Just in case you want to go there (but not necessary,
if you have no problems in your IDE, in case the DoEvents
change in the ThreadClass-MainLoop solves the other
issues)...
'Into an additional Public Class in MidiStreaming.dll
Option Explicit
Private Const HH_CLOSE_ALL As Long = &H12
Private Declare Function HtmlHelp Lib "HHCtrl.ocx" Alias "HtmlHelpA" _
(ByVal hwndCaller As Long, _
ByVal pszFile As String, _
ByVal uCommand As Long, _
ByVal pData As Long) As Long
'a simple wrapper for the "workhorse-call" of the above API (same params)
Public Function ShowHelp(ByVal hwndCaller As Long, _
ByVal pszFile As String, _
ByVal uCommand As Long, _
Optional ByVal pData As Long) As Long
ShowHelp = HtmlHelp(hwndCaller, pszFile, uCommand, pData)
End Function
'and this ensures proper auto-cleanup - just define this object globally
'in some Apps *.bas-module - it terminates itself on App-Shutdown,
'cleaning up the eventually (yet) opened Help-Windows then
Private Sub Class_Terminate()
HtmlHelp 0, vbNullString, HH_CLOSE_ALL, 0
End Sub
Thanks! I chose the easy solution, namely placing a DoEvents just
before the Sleep 1 call.
It works! Search and Print now work as expected.
However, I was under the, perhaps mistaken, impression that DoEvents
is generally considered Bad News, so I was a bit surprised when I read
the inital part of your response above. That said. I've just done a
quick check of playback and nothing seems to have changed. The app
appears to work just as it did since I implemented your MidiStreaming
code - and now the HTML Help Search and Print work too!
But, following your response above, I also addressed again the issue
of cleanup after the possible loading of Html Help.
History: Back in June I had a GPF problem that occurred when the
Form_Unload (main form) included Call HtmlHelp(Me.hwnd, App.HelpFile,
HH_CLOSE_ALL, 0&)
The GPF did not occur IF the .chm file was loaded at program
tear-down. But if the .chm had NOT been loaded, a GPF occurred if
Eudora Mail was loaded immediately after the VB6 prog had ended (in
the IDE).
I got around that by using a form-level var:
If m_HelpFileOpened Then Call HtmlHelp(Me.hwnd, App.HelpFile,
HH_CLOSE_ALL, 0&)
However, now I have enhanced Help to include F1 context-sensitive
help, I have no quick way to determine if the help file has been
loaded or not and thus I cannot set m_HelpFileOpened = True in every
case (obviously it would be easy enough to use FindWindow or track
F1usage, but that's another matter).
The effect is, of course, that the Help file stays loaded when the
program ends, as the HH_CLOSE_ALL line doesn't get executed (because
m_HelpFileOpened = False).
Then I saw the end of your above response, and have placed in
Form_Terminate (main form) the line
HTMLHelp 0, vbNullString, HH_CLOSE_ALL, 0
This appears to work in all cases, without any GPF, whether any help
file was loaded or not and whether the app is running in the IDE or as
an .exe
Therefore I no longer need the form-level variable m_HelpFileOpened
Again, many thanks for your help!
MM
.
- Follow-Ups:
- Re: MidiStreaming problem/conflict with HTML Help
- From: Schmidt
- Re: MidiStreaming problem/conflict with HTML Help
- References:
- Prev by Date: Re: non-vb topic: would anyone recommend a good free webhosting site?
- Next by Date: Are People Making Money in VB6?
- Previous by thread: Re: MidiStreaming problem/conflict with HTML Help
- Next by thread: Re: MidiStreaming problem/conflict with HTML Help
- Index(es):
Relevant Pages
|
