message: MyPresenterSubclass class dnu #resource_Default_view
Should that just point to the Presenter>>resource_Container_view? (seems to work) Ted |
Ted wrote:
> message: MyPresenterSubclass class dnu #resource_Default_view > > Should that just point to the Presenter>>resource_Container_view? (seems > to work) > > Ted When saving that view, a dialog pops up: MyPresenterSubclass.Default view is an existing Array. Do you wish to replace it? I don't think that is correct. Ted |
In reply to this post by Ted
Ted wrote:
> message: MyPresenterSubclass class dnu #resource_Default_view > > Should that just point to the Presenter>>resource_Container_view? (seems > to work) > > Ted I also noticed that when you open the vc in an idea space that there's lots of flickering outside that window going on whenever you change an aspect of one of the controls inside the shell. I've got a dual monitor setup, with the idea space in the secondary monitor. There seem to be at least two hidden windows on the first monitor that flicker when you move, resize, rename or something alike in the view composer. Ted |
Ted,
> I also noticed that when you open the vc in an idea space that > there's lots of flickering outside that window going on whenever you > change an aspect of one of the controls inside the shell. I've got a > dual monitor setup, with the idea space in the secondary monitor. > There seem to be at least two hidden windows on the first monitor > that flicker when you move, resize, rename or something alike in the > view composer. This is quite worrying. Does anyone else see a similar effect? The reason I ask is that the way the new VC works is rather different from the old one. Because we wanted to be able to attach a VC to any running shell (in future) we now create the view being edited as a hidden child of the desktop rather than it being a child of the VC itself. An added benefit of doing this is that the menu bar now appears correctly when editing shell views. So what happens is that the VC now displays an bitmap of the view in it's arenaPresenter (which is, in fact, an ImagePresenter). Every time a change is made then a WM_PRINT message is sent to the view to render it as a bitmap that can be shown in the arena. Problem is that we noticed that hidden views don't always print correctly view WM_PRINT so you'll see that in VC>>composingView:isOwned: we keep the view visible but move it off the screen to the #hidingOffset position. This seems to work fine, without flicker, on the single monitor systems we have tried and on my 3 monitor desktop. Perhaps, your display drivers aren't quite so forgiving and don't like the idea of positioning windows way off the screen. Any further experimentation/information would be welcome. Note: there should only be ONE hidden view, not two as you suggest. -- Andy Bower Dolphin Support www.object-arts.com |
Hi Andy,
Some further details > >>I also noticed that when you open the vc in an idea space that >>there's lots of flickering outside that window going on whenever you >>change an aspect of one of the controls inside the shell. I've got a >>dual monitor setup, with the idea space in the secondary monitor. >>There seem to be at least two hidden windows on the first monitor >>that flicker when you move, resize, rename or something alike in the >>view composer. > > > This is quite worrying. Does anyone else see a similar effect? > > The reason I ask is that the way the new VC works is rather different > from the old one. Because we wanted to be able to attach a VC to any > running shell (in future) we now create the view being edited as a > hidden child of the desktop rather than it being a child of the VC > itself. An added benefit of doing this is that the menu bar now appears > correctly when editing shell views. > > So what happens is that the VC now displays an bitmap of the view in > it's arenaPresenter (which is, in fact, an ImagePresenter). Every time > a change is made then a WM_PRINT message is sent to the view to render > it as a bitmap that can be shown in the arena. Problem is that we > noticed that hidden views don't always print correctly view WM_PRINT so > you'll see that in VC>>composingView:isOwned: we keep the view visible > but move it off the screen to the #hidingOffset position. > > This seems to work fine, without flicker, on the single monitor systems > we have tried and on my 3 monitor desktop. Perhaps, your display > drivers aren't quite so forgiving and don't like the idea of > positioning windows way off the screen. Any further > experimentation/information would be welcome. If I do a full-screen IdeaSpace on my first monitor, I don't get the flickering. However, if I do non-full screen (especially leaving space in the lower righthand corner) I see flickering, one flicker at the bottom, about the size and colour of the workspace in the vc and one flicker just above, but typically overlapping. It could just be the same space flickering twice but such a short flicker that only part of it is visible. There are typically two flickers, sometimes only one (but again, that could be a timing issue). If I have an app window over that corner (like this mail message) I don't see the flickering. As my two monitors are different (both flat panel, but different make, size and response time), I thought I'll swap them. The flicker is visibly different (the 'faster' screen shows less of it) but it's still visible. I'm using a nVidea Geforce FX5700-256Mb graphicscard. Both monitors set to 1280*1024 and 32bit colour. I also tested the ViewComposer on its own (not in an IdeaSpace) but unfortunately to the same result (if the bottom righthand corner of the *desktop* is visible, I can see the flickering) > > Note: there should only be ONE hidden view, not two as you suggest. > I did notice an extra item in my task bar :-) HTH Ted |
In reply to this post by Andy Bower-3
Andy,
> > I also noticed that when you open the vc in an idea space that > > there's lots of flickering outside that window [...] > > This is quite worrying. Does anyone else see a similar effect? Just in case the information is useful: I attempted to run D6 in 256-colours yesterday (I was testing something unrelated, and thought I might as well fire up the beta and see what happened), and saw the same flickering when the VC was invoked. I'm not suggesting that this is a problem in any way, but it be of some help for diagnostic purposes. (BTW D6 seemed to work fine in 16-bit on Win2K, and was only marginally compromised in 256-colour mode ;-) -- chris |
Free forum by Nabble | Edit this page |