|
Brian
tried this one well...still no luck
here is the Error Message...
error C2664: 'GetNextView' : cannot convert parameter 1 from 'struct __POSITION *' to 'struct __POSITION *& '
A reference that is not to 'const' cannot be bound to a non-lvalue
|
|
|
|
|
Ah - it wants a reference.
Try:
POSITION pos = pDoc->GetFirstViewPosition();
CView* pView = pDoc->GetNextView( pos );
It wants to update the position, even though in this case we know that there is only one...
Dave
|
|
|
|
|
Sopmething is very wrong with your design if you need to do that. The document is not responsible for displaying data; the view is.
|
|
|
|
|
well im trying to get my doc to update the view every time I change the data in my doc.
I need to draw something ont he view based on the data from my doc.
I thought I;d get a pointer to the Device context of the view and access it through my DOC and do the drawing.
Any ideas howelse this can be done?
thanks
|
|
|
|
|
Loooser wrote:
I need to draw something ont he view based on the data from my doc.
That what the view is doing: Showing an aspect ('a view') of the documents data.
That is, the view takes the data it wants to use from the document and displays it.
Loooser wrote:
im trying to get my doc to update the view every time I change the data in my doc
Try to look into UpdateAllViews(). It is exactly what you want.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
Hiya when I make a c++ console app in .NET now, sometimes I get a warning saying:
C4995: '_OLD_IOSTREAMS_ARE_DEPRECATED'
This is when I am using cout or cin..
How do I clear this warning message??
Thanks,
grahamoj
|
|
|
|
|
replace :
#include <iostream.h>
with
#include <iostream>
eperales
|
|
|
|
|
I've found a way to display a 35MB raw image, loading it into a CBitmap object using CreateDIBSection, then CGDIObject::Attach and then CBitmap::SetBitmapBits.
Now I have the 4096x2700 pixels on the screen, but when I scroll I see a lot of flickering in the scrolling direction: I'm already using double buffering (selecting the bitmap in a compatible memory DC and the "BitBlt-ting" it on the primary DC).
Any hint?
Thanks.
|
|
|
|
|
try to override WM_ERASEBKGND in the view and return true insted of default.
|
|
|
|
|
35 MB is a huge image. Double buffering and using the BitBlt API call is probably the best you can do. The mere size of the image involved is most likely the problem.
You can try overriding OnEraseBkgrnd() but I doubt you will see much improvement. 
Any way you can reduce the size of the image?
Maybe reduce the # of colours?
|
|
|
|
|
No, I can't change the image size or format, because I have to work with medical hi-res raw images.
Can you explain me what may change if I use the OnEraseBkgrnd() instead of the OnDraw() method?
|
|
|
|
|
OnDraw(), it's handler for the WM_ERASEBKGRND message which allow or forbid clearing of the window DC before calling WM_PAINT, usually by drawing a large rect using the default background color.
To use it you insert a handler function for WM_ERASEBKGRND from the class view in VC++ 6 or from the 'Messages' in properties panel in VC++7.
To disable clearing the DC, you should remove the deafult return line and just return true, like this:
BOOL CChildView::OnEraseBkgnd(CDC* pDC)
{
return true;
}
This will disable clearing the DC before painting, and it remove flickering in many cases.
The DC pointer is passed here to allow filling the background with with differnt color or pattern, but not usually used to draw the main image.
|
|
|
|
|
Concerning OnEraseBkgnd() -- See the post by MAAK. That is a good explanation.
I do a lot of programming with medical images - is the image you're working with in DICOM format?
How do you acquire it? Is it CT data? MRI?
4000x1000 pixels is a whopping size...what type of data are you displaying with this image?
|
|
|
|
|
I'm using some HIRES 4096x2700 (24 bit per pixel) from the VHD archive.
|
|
|
|
|
Ah, the Visible Human...
I don't have any timings or performance figures to give you, but you could try StretchBlt'ing the image to a MemDC only once with the idea to cut the image size in, say half. Once you have StretchBlt it to memory, you could then BitBlt the reduced image to the DC. Technically, you should only have to shrink the image once in memory (ie: create a temporary bitmap in memory). The smaller image may scroll smoother. You could also use the OnEraseBkgnd() handler in combination with the reduced image. It depends what you are trying to accomplish with your program. You may also want to consider reducing the colour depth, again, depending on the scope of your application.
Upgrading the video card and/or processor may help as well.
Unfortunately, you won't find a faster way of displaying the image than the BitBlt API call...
Aside from all that....
|
|
|
|
|
Newbie Question:
I have a C/C++ Dialog-based app using Visual Sutdio 6.0.
I begin and intensive background processing task using,
AfxBeginThread with THREAD_PRIORITY_BELOW_NORMAL.
All user actions seem to be suspended until this processing task completes.
I would like user actions, such as repositioning the Dialog and clicking buttons to work immediately.
I have a periodic update on the screen, UpdateData(), to inform the User of progress of the background task and tried placing a Sleep() statement in their but that does not seem to work.
Any help would be very much appreciated.
|
|
|
|
|
If you are doing the intensive background processing in your worker thread, what is your main thread doing during this time? Are you just waiting for the worker thread to complete? If the main thread just exits the current message handler, and continues to execute the main message loop, then it should be able to handle new messages (user input) with no problems.
Post the code for how you are creating the thread - it should make things a bit clearer from this end...
Dave
|
|
|
|
|
Dave,
Thank-you for response. Here is the multi-step approach I use to run a background thread that can update Dialog class variables during it's execution.
=== STEP 1
Use AfxBeginThread to run a function, zdisplay()
CWinThread *pThread = AfxBeginThread( &zdisplay, this->m_hWnd, THREAD_PRIORITY_BELOW_NORMAL );
ASSERT( NULL != pThread );
===STEP 2
Use zdisplay() function to endlessly loop and send a message, WM_APP_UPDATE_DLG.
UINT CCryptoDlg::zdisplay( LPVOID pParam )
{
int xx=1;
do
{
::SendMessage( (HWND)pParam, WM_APP_UPDATE_DLG, (WPARAM)buf, 0 );
if (xx == 1)
{
Sleep(1000);
}
} while(TRUE); /*end do statement*/
return 0;
} /*end zdisplay() function*/
===STEP 3
Define message WM_APP_UPDATE_DLG to run function OnUpdateDialog().
ON_MESSAGE( WM_APP_UPDATE_DLG, OnUpdateDialog )
===STEP 4
The code in OnUpdateDialog () is the intensive background task that seems to be disallowing the main dialog to respond to user I/O.
Much thanks,
Robert
|
|
|
|
|
What's happening is your background thread isn't doing the processing at all. It is sending a message to the main thread, telling it to do the operation. Since the main thread is now busy doing the intensive operation, it obviously cannot respond to user input. In addition, SendMessage() is a blocking call, so your worker thread is suspended during this as well.
Change the intensive processing to happen inside the worker thread, and it should post (not send) a message to the main thread whenever it needs to update the display. This will keep the main thread free to process user input, but still only have one thread modifying the display at a time.
Dave
|
|
|
|
|
Hi Dave,
Thank-you for your response. I think I'm getting it.
zdisplay() is clearly a worker thread since it is so-started by AfxBeginThread().
I assumed (badly) that since OnUpdateDialog() function (the intensive processing) was started from a message sent BY the zdisplay() function that it too was of the 'worker' variety.
Clearly you are correct, but what tells you that OnUpdateDialog() is considered a 'main' thread rather than a 'worker' thread?
Sorry for all the dumb questions.
Thank-you very much,
Robert
|
|
|
|
|
Windows are associated with the thread in which they are created. When you send or post a message to a window handle, it will be processed by the thread that owns that window (which may be the same thread). In addition, since worker threads do not have a message pump, they cannot process any messages.
Take a look through some of the thread articles, particularly the ones talking about worker threads vs. user interface threads if you are interested.
Dave
|
|
|
|
|
Hi Dave,
Thanks again. I wrote a quick little test program to experiment with this and it works just like you indicated - no surprize.
I found PostMessage() in the Win32 SDK and will implement that as well. It looks like it takes the same parameters.
Thanks for helping me through this. I'm an old C warhorse and C++ and MFC are new to me.
|
|
|
|
|
|
who used visual basic knows that it has a holly function :
DoEvents()
it processes events while working !
int i=0;
while(1)
{
i++;
DoEvents();
}
this is the C++ version :
bool DoEvents()
{
MSG msg;
while (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) == TRUE)
{
if (GetMessage(&msg, NULL, 0, 0) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
return TRUE;
}
}
return 0;
}
//rate me or hate me
I am the mighty keeper of the book on knowledge . Contact me to get your copy .
|
|
|
|
|
Thanks TomKat!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
