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? |
"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 |
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] |
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 > 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 |
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] |
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... :-). |
Free forum by Nabble | Edit this page |