View composer bug

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

View composer bug

Bob Jarvis
I've been trying to build a view and have been encountering problems.
Here's the steps to follow to recreate the error:

   Start with a virgin image:

   1. Start the image.
   2. Click "Close" on the Tip-of-the-day dialog.
   3. Open a class hierarchy browser.
   4. Right-click on the Object class, click Find..., enter "Shell" in
the text box, click OK.
   5. Right-click on the Shell class, click New..., enter "TestShell"
in the text box, click OK.
   6. Right-click on the TestShell class, click Views, click New...
   7. Click Modify, click "Set Menu Bar...".
   8. Double-click on the "untitled menu" entry, enter "&File" in the
text box, click OK.
   9. Double-click on the "untitled command" entry, enter "E&xit" as
the item text, enter "#exit" as the command, and click on the OK
button.
  10. Click on the OK button on the menu composer.
  11. Change the layout manager for the ShellView to be a
ProportionalLayout.
  12. Change the isVertical aspect of the ShellView's layout manager
to "true".
  13. Press Ctrl-T to bring up the toolbox.
  14. Build the following view hierarchy, making the noted aspect
changes:

      ShellView - layout manager=ProportionalLayout, isVertical=true
         ContainerView - layout manager=ProportionalLayout,
isVertical=false
            MultipleSelectionListBox
            Splitter
            MultilineTextEdit
         Splitter
         ContainerView - layout manager=GridLayout

  15. Click on the File menu, click on Save As..., click OK.
  16. Close the view composer.
  17. Right-click on the TestShell class, click Views, click on Edit,
click on "Default view", and...

         BOOOOM!!!

It appears that something in the view resource is getting trashed (it
appears to be trying to resolve the class name "LookupTable" but the
"Look" has been trashed with 4 bytes of random characters), and
complains because it can't find "<package path>\Dolphin.pak".  I've
had occasions where this crashes, and I've had other occasions where
it worked OK, although there may have been minor variations in the
order of operations (i.e. I may have set the menu text and command
later in the sequence of operations).  Help?


Reply | Threaded
Open this post in threaded view
|

Re: View composer bug

rush
"Bob Jarvis" <[hidden email]> wrote in message
> "Look" has been trashed with 4 bytes of random characters), and
> complains because it can't find "<package path>\Dolphin.pak".  I've

no help, but the rare random 4 bytes trash appears to be some long time
ghost of  Dolphin. Since it seems you have found reliable way to reproduce
it, maybe its days are finally numbered.

I am certanly interested to see how it will unfold, since in one of my apps
I also do get very rare 4 bytes trash which I have been attributing to some
external dll, but who knows.

rush


Reply | Threaded
Open this post in threaded view
|

Re: View composer bug

Bill Schwab-2
In reply to this post by Bob Jarvis
Bob,

> It appears that something in the view resource is getting trashed (it
> appears to be trying to resolve the class name "LookupTable" but the
> "Look" has been trashed with 4 bytes of random characters), and
> complains because it can't find "<package path>\Dolphin.pak".

I'll join Rush in seconding that this might have legs, but, I'll admit that
I can't reproduce it.  That might be in part because I am now typing on a P3
running Windows 2000, which was not long ago an NT4 machine only a couple of
clock cycles ahead of the garbage collector - literally :)   I was seeing
corruptions similar to yours, and at a rate that was too low to track down
but large enough that I had lost confidence in the machine.  Perhaps
noteworthy is that I had problems with the binary filer in general, not just
in the VC, so there could be some kind of stream, weak collection, or VM bug
behind this???

Rush mentioned explaining away a problem based on an external DLL.  Possible
explanations in my situation included a Novell client that might have been
causing problems.  Since installing 2k and uninstalling the Novel client, I
haven't seen a problem.

In looking at your instructions, I noticed that I'm not clear on where to
put the container view listed just above 15 - it gets a grid layout, but, is
there anything in it?  Or, is it a container added previously and altered?


> I've
> had occasions where this crashes, and I've had other occasions where
> it worked OK, although there may have been minor variations in the
> order of operations (i.e. I may have set the menu text and command
> later in the sequence of operations).  Help?

This sounds like a problem for my view generator package.  I'm curious to
see if we can get it to reproduce the problem on a machine or two.  Being
driven by code, it would be possible to get a sequence that's not varied by
human error.   The bad news is that the view generator doesn't do menus at
present.  I use it mostly to (re, re, re,...<g>) build a big ugly view for
one of our research projects, and that doesn't require menus.  However, it
should be possible to grab onto the views that are added and send them some
messages from a post-generation block.

An older version of the generator is on my web site already, but, I've made
some improvements since packaging it.  I'll try to hook into the
post-generation stage and see if I can get it on the web today.  The plan
would be for you to tweak the code to generate the view to reproduce your
scenario and hopefully the corruption.  Then others could try the same
sequence by installing two packages followed by a DoIt.

Which OS are you using?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: View composer bug (Me Too!)

Christopher J. Demers
In reply to this post by rush
rush <[hidden email]> wrote in message
news:a7friq$2vtp$[hidden email]...

>
> "Bob Jarvis" <[hidden email]> wrote in message
> > "Look" has been trashed with 4 bytes of random characters), and
> > complains because it can't find "<package path>\Dolphin.pak".  I've
>
> no help, but the rare random 4 bytes trash appears to be some long time
> ghost of  Dolphin. Since it seems you have found reliable way to reproduce
> it, maybe its days are finally numbered.
>
> I am certanly interested to see how it will unfold, since in one of my
apps
> I also do get very rare 4 bytes trash which I have been attributing to
some
> external dll, but who knows.

Yes, I have experienced this problem as well.  I never found a way to
exactly reproduce it in a repeatable fashion, but it has happened to me
quite a few times.  In fact this bug caused me to totally stop using the
Dolphin View Composer on Windows NT because it kept trashing my views.  I
have never experienced this problem on my Windows 2000 machine.  I spent
some time trying to debug the problem, but I ultimately just gave up.  The
problem persists even in new images, but only my Windows NT machine.  I have
posted about this twice before

http://groups.google.com/groups?q=%22STB+corruption+on+View+test+in+ViewComp
oser...%22&hl=en&btnG=Google+Search ) if the url is mangled do a
groups.google.com search for "STB corruption on View test in
ViewComposer...".  I am glad I am not the only one to experience this
problem.  I am not sure if it is an STB or a View problem.  If it is an STB
problem then it could have an impact on my end users id they use Windows NT.

I would really like to see this problem resolved, so I can have full use of
Dolphin on my NT machine again.

Chris


Reply | Threaded
Open this post in threaded view
|

Re: View composer bug

Bill Schwab-2
In reply to this post by Bill Schwab-2
Bob,

Here's the code for my view generator:

  needle.anest.ufl.edu/anest4/bills/MVPgeneratorsD4.zip

FWIW, I can't get to it if I put http:// in front of it.  MS innovation
issues aside<g>, make a backup, install the two packages, and look at
ViewGenerator class>>fourByteBug.

I haven't worked in the menus yet, but, that should be as simple as sending
#menuBar: at the right place.  It looks like you can forget about the
post-generation block; but, I did do a little refactoring to expose the
context view (which is useful if a little dangerous).



Hopefully you'll be able to use this to automate corrupting a view - happy
crashing :)



Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: View composer bug

Bob Jarvis
In reply to this post by Bob Jarvis
Bill, Rush, & Chris,

Thanks for the follow-ups.  I'm still at a loss to explain WHY this
crash occurs, but I have found a workaround (which may be a
"supposed-to-be" instead of a "workaround" - not sure).  Anyways, if
you add a ContainerView directly under the topmost Shell, set the
layout manager of this new ContainerView to BorderLayout, and make
everything else a child of the new ContainerView, everything works.
This may just be hiding the problem, but at least I don't get a
debugger.  I noticed that I had done this same thing on other views
I'd created for other projects, so maybe this is what's supposed to be
happening?  Andy/Blair - any thoughts on this?

After having read Chris Demers note I'll point out that this occurred
on a WinNT box with service pack 6a applied.  Haven't tried it on my
WinME machine.

Bill -
>In looking at your instructions, I noticed that I'm not clear on
where to
>put the container view listed just above 15 - it gets a grid layout,
but,
>is there anything in it?  Or, is it a container added previously and
altered?

There's nothing in the bottom ContainerView - just an empty view with
a GridLayout as the manager.  (The idea is that sub-views will be
added dynamically as needed to display data).  In words, what I've got
is a ShellView which contains three views - a ContainerView, followed
by a Splitter, followed by another ContainerView.  The first
ContainerView has three children - a MultipleSelectionListBox, a
Splitter, and a MultilineTextEdit.  Based on what Chris Demers said my
guess is that you won't be able to reproduce this problem under Win2K
- it sounds like it may be NT-specific.  (Of course, we all understand
that nothing Microsoft produces could *ever* have a bug in it... :-).