Help! Getting ->Show() to work.

[Earl Colby Pottinger]

I am doing something wrong, somehow the right brain cells are not firing.

If you look at my BePrint, BePrinter, or DigitalAnalogScope programs you see
that I do not use the View->Show() or Window->Show() to refresh my display -
rather I either shink and grow the screen or move it away and return it to
force a proper call to redraw the screen.

This however causes a lot of flicker, and in later version of the scope
program I want to redraw the display as often as makes sense to give a
'real-time' display.

If anyone has the time could they quickly look at my code and tell me what
stupid thing I am doing, or what part of the BeBook I overlooked. And does
anyone have a better explaination of the ->Lock() function.

Even a pointer to a old Newsgroup message would be nice, I tried searching
them but I get so many hits (or none at all) that is like look for a needle
in a haystack. Even just a subject line to search for would.

Thanks to anyone who can spare the time.

Earl Colby Pottinger

PS: I am on a modem, that is why I have not gotten int BeShare.

[m***@xs4a11.nl]

Post by Earl Colby Pottinger
I am doing something wrong, somehow the right brain cells are not firing.
If you look at my BePrint, BePrinter, or DigitalAnalogScope programs you see
that I do not use the View->Show() or Window->Show() to refresh my display -
rather I either shink and grow the screen or move it away and return it to
force a proper call to redraw the screen.

You shouldn't call Show() to refresh your display, nor should you move
things around and then move them back in order to refresh the display.
(you *do* need to call BWindow::Show() at least once, otherwise your
window is not even going to be visible).
What you need to do in order to refresh a view is Invalidate() it (i.e.
call BView::Invalidate() on it).

Marco

[Earl Colby Pottinger]

Post by Earl Colby Pottinger

Post by Earl Colby Pottinger
I am doing something wrong, somehow the right brain cells are not firing.
If you look at my BePrint, BePrinter, or DigitalAnalogScope programs you

see

Post by Earl Colby Pottinger
that I do not use the View->Show() or Window->Show() to refresh my

display -

Post by Earl Colby Pottinger
rather I either shink and grow the screen or move it away and return it to
force a proper call to redraw the screen.

You shouldn't call Show() to refresh your display, nor should you move
things around and then move them back in order to refresh the display.
(you *do* need to call BWindow::Show() at least once, otherwise your
window is not even going to be visible).
What you need to do in order to refresh a view is Invalidate() it (i.e.
call BView::Invalidate() on it).

Thank you, I do call BWindow::Show near the start to get my windows/views to
display, it was updating they that was the problem. I will test your
suggestion tonight. Again thanks alot. I don't remember seeing that clearly
stated in the 'Programming the Be Operating System' book. Still partly it is
probably my age, I can't seem to wrap my head around C++ as you would see if
you read my code, it probably is written up in a way thet is clear as day to
real C++ programmers.

Earl Colby Pottinger

PS. If this work with my hacky (that is as in cough cough!) code, I will have
an new update on BeBits by morning.

[Earl Colby Pottinger]

Well, it did not work. :{

But I found some design errors in my code that let's it work for now but
interfers with changing the code around so I have to fix that first. Hope
your suggestion works after I work out my own errors first.

Again thanks for the help.

Earl Colby Pottinger

[m***@xs4a11.nl]

Post by Earl Colby Pottinger
Well, it did not work. :{

Well, then you did it wrong. :)
The code for your "Digital/Analog Scope" app is a bit on the unreadable
side, but if I'm reading it right, it looks like you're using using two
overlapping sibling views, and I think that may be the cause of some
problems:

// edited for readability
aView_Rect.Set(10, 10, 850, 690);
aView2_Rect.Set(30, 30, 829, 429);
aView = new Digital_Scope_View(aView_Rect, "Digital_Scope_View" ) ;
aView2 = new Digital_Display_View(aView2_Rect,"Digital_Scope_Display'" )
aWindow->AddChild(aView);
aWindow->AddChild(aView2);

Those last two lines should be:
aWindow->AddChild(aView);
aView->AddChild(aView2);

Then in your application's MessageReceived(), instead of this:

case REFRESH_SCREEN: { // Redraw the window.
aWindow->MoveBy(999.0,999.0);
aWindow->MoveBy(-999.0,-999.0);
break; } // Forces a redraw of the window.

do something like this:
case REFRESH_SCREEN:
aWindow->Lock();
aView->Invalidate();
aView2->Invalidate();
aWindow->Unlock();
break;

Marco

[Earl Colby Pottinger]

First, Thank you for your help and time

Post by m***@xs4a11.nl

Post by Earl Colby Pottinger
Well, it did not work. :{

Well, then you did it wrong. :)
The code for your "Digital/Analog Scope" app is a bit on the unreadable
side

Question? Why do you find it unreadable? I find the normal 'C/C++' style
that way because code is spread so wide often I can't even see all the code
for a single function on my screen. I try to write my code so all the
related functions appear on the screen at the same time.

Post by m***@xs4a11.nl
but if I'm reading it right, it looks like you're using using two
overlapping sibling views, and I think that may be the cause of some

Interesting. Yes they are over lapping, aView2 sits on top of aView (to be
called aView1 in the next version). The programming BeOS book says this is
ok, but you can note those were non-overlapping views. I did not think
anything of it because as you can see the present code worked for me,

Post by m***@xs4a11.nl
// edited for readability
aView_Rect.Set(10, 10, 850, 690);
aView2_Rect.Set(30, 30, 829, 429);
aView = new Digital_Scope_View(aView_Rect, "Digital_Scope_View" ) ;
aView2 = new Digital_Display_View(aView2_Rect,"Digital_Scope_Display'" )
aWindow->AddChild(aView);
aWindow->AddChild(aView2);

So yes, here I have aView2 on top. And it seems to work ok. You can bet the
word 'seems' is the killer problem with my code.

Post by m***@xs4a11.nl
aWindow->AddChild(aView);
aView->AddChild(aView2);

Interesting, a very easy change to make.
See, part of my problem is my lack of knowledge, I will not be surprise if
this fixes my problem, but I don't understand why it does. If Haiku takes
off I hope someone writes an expanded programming book.

Post by m***@xs4a11.nl
case REFRESH_SCREEN: { // Redraw the window.
aWindow->MoveBy(999.0,999.0);
aWindow->MoveBy(-999.0,-999.0);
break; } // Forces a redraw of the window.
aWindow->Lock();
aView->Invalidate();
aView2->Invalidate();
aWindow->Unlock();
break;

Thanks, two questions if you don't mind. Is there any real reason to do
aView->Invalidate() as nothink changes or needs to be redrawn there.

Do you know where I can get a bit more information on Lock() and Unlock()?
The BeBook still has a lot to desire in understanding this. I think I know
what it means, I don't know that I know what it means.

Earl Colby Pottinger

[m***@xs4a11.nl]

Post by Earl Colby Pottinger
Question? Why do you find it unreadable? I find the normal 'C/C++' style
that way because code is spread so wide often I can't even see all the code
for a single function on my screen. I try to write my code so all the
related functions appear on the screen at the same time.

I have a big monitor (1600x1200) and don't have that problem. I like the
code to be spread out a bit because it's easier to see at a glance where
code-blocks begin and end. I had a really hard time even finding where a
function began in your code, because it was so "dense".
I assume you have a small screen. Not just from the coding style, but
also from the code itself: moving the window by 999 pixels and then back
would not have done much on my monitor (or most people's monitors these
days, I suppose), since the window would likely have stayed on-screen the
whole time.

Post by Earl Colby Pottinger
Interesting. Yes they are over lapping, aView2 sits on top of aView (to be
called aView1 in the next version). The programming BeOS book says this is
ok, but you can note those were non-overlapping views. I did not think
anything of it because as you can see the present code worked for me,

I don't have this book you mention, but the BeBook explicitly says that
is strongly recommended not to use overlapping sibling views. Note the
word "sibling". It is OK for a child view to overlap its parent view
(in fact, it's expected).

Post by Earl Colby Pottinger

Post by m***@xs4a11.nl
// edited for readability
aView_Rect.Set(10, 10, 850, 690);
aView2_Rect.Set(30, 30, 829, 429);
aView = new Digital_Scope_View(aView_Rect, "Digital_Scope_View" ) ;
aView2 = new Digital_Display_View(aView2_Rect,"Digital_Scope_Display'" )
aWindow->AddChild(aView);
aWindow->AddChild(aView2);

So yes, here I have aView2 on top. And it seems to work ok. You can bet the
word 'seems' is the killer problem with my code.

Just because you added aView2 last does't mean it will actually be on top.
The only way to guarantee it being on top is to add it as a child of aView,
instead of as another child of the window. The BeBook also mentions this
explicitly: "Siblings don't draw in a predefined order. If they overlap,
it's indeterminate which view will draw last - that is, which one will draw
in front of the others."

Post by Earl Colby Pottinger
Thanks, two questions if you don't mind. Is there any real reason to do
aView->Invalidate() as nothink changes or needs to be redrawn there.

In that case you don't need to invalidate it. You only need to invalidate
it if you want to force something to be redrawn. I wasn't sure which view
did what, as I didn't run the code. Note that if you want to play some
kind of animation (and a scope certainly qualifies as that), you will want
to set your view's color to B_TRANSPARENT_COLOR. This will prevent the
system from erasing your view before it is asked to redraw, which would
cause flickering.

Post by Earl Colby Pottinger
Do you know where I can get a bit more information on Lock() and Unlock()?
The BeBook still has a lot to desire in understanding this. I think I know
what it means, I don't know that I know what it means.

In a nutshell: locking an object grants the caller exclusive access to the
object. Some objects require that the object be locked before calling
certain member functions, since otherwise multiple threads could be trying
to do things to the object at the same time, which would be Not Good.
I've only ever used the BeBook, so I don't know of any other place that
would explain this. I think the BeBook does a reasonable job. Note that
the concept of locking is explained in the BLooper section (BWindow
inherits its Lock() function from BLooper), and the BWindow section
lists which BWindow-functions require locking the window before calling
them.