Re: Invalid access to memory location for X86_Microsoft.Windows.Common-Controls.... COMCTL32.dll

Hi Tim,

self when: #closeRequested: send: #onCloseRequested: to: self.
And display a message box to verify - I'm not sure if this might be the cause?).

There is an interesting discussion of this at:

http://groups.google.com.au/group/comp.lang.smalltalk.dolphin/browse_frm/thread/82bb65eeb50b59c1/ee23d61be4d4256c

In an #onCloseRequested: event handler, personally I think the best
solution is to use a taskModal MessageBox ... ie (MessageBox new
beTaskModal; confirm: 'confirm me').

So now I am left wondering how I can do a "deferredAction"?

[self doSomethingInTheMainProcess] postToInputQueue.

Check out the method comments in InputState>>loopWhile: and
InputState>>processDeferredActions

was something in block closure to do this (although I can't seem to locate
it now?). But it also occurs to me that any deferral I do will only end up
causing a #closeRequested: event and so it will be a nasty loop... and do
I then have to have some flag hack to not ask again?

If you can get away with using a taskModal MessageBox you can avoid
all this. In a single main window application, there should be no
usability problems making the MessageBox taskModal.

It all seems very nasty and I'm wondering if there are any helpful tips (Steve?
OA - can you provide something nicer than this?)

For MessageBoxes you have the taskModal option, and for dialogs you
have the option of using the new #isInProc style. It would be nice to
see some constructor methods (ie Dialog class>>showModalInProc*) in
the base image to make the inProc option easier to access.

Over the past year or so, I have switched to using mostly taskModal
MessageBoxes and inProc Dialogs. I find inProc Dialogs easier to test
and these forked process issues disappear.

If I do use a non-taskModal MessageBox or a modalLoop dialog, I always
avoid doing anything that involves a view after showing them. The
thing to be aware of is that you are no longer in the main process,
and as a general rule, you should only send messages to views/
presenters/models in the main process. The dialog does adjust process
priorities to try and avoid problems in this situation, but wherever
you have multiple processes, you have the potential for intermittent
bugs.

So instead of writing: (MessageBox confirm: 'this') ifTrue: [self
doSomething]. I would write (MessageBox confirm: 'this') ifTrue:
[[self doSomething] postToInputQueue].

Hope this helps,
Steve
--
swaring@xxxxxxxxxxxxxx

.

Relevant Pages

  • Re: CreateProcess
    ... If the process calls MessageBox function, how to avoid the message window ... > the error message showing on the desktop? ...
    (microsoft.public.win32.programmer.kernel)
  • Re: CString to const char*
    ... (MessageBox instead of MessageBoxA) ... and avoid all the hassle... ... Unfortunately I do not have control over the methods being called, i.e. the socket functions, or are there TCHAR equivilents? ...
    (microsoft.public.vc.language)
  • Re: Detect when ActiveForm changes
    ... instantiated outside of my application (e.g., MessageBox or UITypeEditor ... motivation of this question was to avoid doing that. ...
    (microsoft.public.dotnet.languages.vb)
  • Macro : confirm Delete
    ... Then a messagebox appears to confirm to delete the data. ... How can I klick "Delete" automatically (or avoid this ...
    (microsoft.public.excel.programming)