executable freezes

I have an application that works from the development environment, but
when I deploy it to an executable, it usually freezes when a
particular widget is clicked.  "Usually" but not always - once it
worked without freezing, but the same executable then froze the next
time I ran it.  The widget in question is a radio button that is part
of a Yes/No question on the GUI.  I have looked carefully at the
#model: and #createComponents methods in my shell class, as well as
the underlying model aspects, and everything seems to be in order.
For example, here is the code for the underlying setter for the
widget, which is named i1b.  The 'Yes' radio button is named i1a and
the 'No' radio button is named i1b.

i1b: aBoolean
        i1b := aBoolean.
        self trigger: #i1bChanged.
        aBoolean ifTrue: [
                self i1a: false
        ].

I use this kind of code in all of the radio button sets to make sure
only one is selected at a time.  Clicking any of the other radio
buttons in the GUI does not cause the screen to freeze.

The model is fairly small, but it is instantiated by a model that has
many instance variables - so many that I had to create this "child"
model to handle the last few widgets that I needed to put into the
shell.  That is, this is a case where I needed two models (and two
shells, and more than two views) to handle all the widgets I needed on
a multi-tab data entry form.  i1bPresenter is the last instance
variable in the child shell.

Can anyone suggest why the GUI freezes when I click the i1b radio
button?  I have tried deploying a few different ways:  with default
options, with all options unchecked (so that nothing is stripped),
with some options checked.  Is the solution somewhere else entirely?

Thanks very much.

Ted Shen

Ted Shen wrote:

> Can anyone suggest why the GUI freezes when I click the i1b radio
> button?  I have tried deploying a few different ways:  with default
> options, with all options unchecked (so that nothing is stripped),
> with some options checked.  Is the solution somewhere else entirely?

I can't help directly, but a few questions may help diagnose the problem.

Is the CPU running at 100% for as long as the application is frozen ?

You said that "i1b" was the last widget in the whole application.  If you add
another widget does the problem go away, stay with i1b, or move to the new one
?

BTW, you can add tracing to a deployed app, by using (for instance):

    Notification signal: 'a string'.
or
    SessionManager current trace: 'aString'.

which (in a deployed application) will write 'a string' to the Windows' debug
stream, which can be read with tools like the (highly recommended) DebugView
from SysInternals.  See:

    http://www.sysinternals.com/ntw2k/freeware/debugview.shtml



    -- chris

> Is the CPU running at 100% for as long as the application is frozen ?
Yes, as long as the application is frozen, the CPU is at 100%.

>
> You said that "i1b" was the last widget in the whole application.  If you add
> another widget does the problem go away, stay with i1b, or move to the new one
> ?
I added a text entry widget after i1b, and the problem stayed with
i1b.  I can enter text in the text entry widget, or click on i1a (the
'Yes' radio button), and the app continues running as desired.  But if
I then click i1b, the app freezes.

Thanks for the tip on Notification and DebugView; I'll look into this.

Ted

"Ted Shen" <[hidden email]> wrote in message
news:[hidden email]...
...
> Can anyone suggest why the GUI freezes when I click the i1b radio
> button?  I have tried deploying a few different ways:  with default
> options, with all options unchecked (so that nothing is stripped),
> with some options checked.  Is the solution somewhere else entirely?

There was once a bug where Dolphin would freeze if a radio button that was
not in a container view but directly on a dialog view was clicked.  You can
search the group for more info about it.  I don't remember if it got fixed.
I have not run into it, but that may be because I always put my radio
buttons in container views now.

It may be helpful for debugging if you override onUserBreak in your
SessionManager to write a crash dump.  That way, assuming Ctrl-Break works,
you can see what the stack looks like.

Chris

Moving the radio button into a container view was the solution.  Those
two radio buttons were outside of container views, and directly on a
shell.  All the other radio buttons (and other widgets) were inside
container views.

The i1a radio button was also outside a container view, yet did not
cause a freeze.  Perhaps something for Object Arts to work on.

Thanks for finding the solution.

Ted

"Christopher J. Demers" <[hidden email]> wrote in message news:<[hidden email]>...

"Ted Shen" <[hidden email]> wrote in message
news:[hidden email]...
> Moving the radio button into a container view was the solution.  Those
> two radio buttons were outside of container views, and directly on a
> shell.  All the other radio buttons (and other widgets) were inside
> container views.
>
> The i1a radio button was also outside a container view, yet did not
> cause a freeze.  Perhaps something for Object Arts to work on.
>

A quote from the Dolphin 5.0 release notes:

"#102: This is a manifestation of the "Dialog navigation goes into infinite
loop sending WM_GETDLGCODE" Windows bug. It is occurring because in a raw
dialog there is no subsequent 'group' to tab to. The OK button is now marked
as a group stop. It has also been necessary to mark the radio button as a
group stop in its toolbox resource, and it will be necessary to manually
turn this off on radio buttons added after the first in a group."

Essentially it is a bug in the Windows IsDialogMessage() function. Under
certain circumstances (most of which we have been able to workaround) this
can go into an infinite loop, unsually when attempting to find the next
control to tab to, but in this case probably attempting to enumerate the
radio buttons in a group.

Regards

Blair

Thanks for the clarification, Blair.

Ted