|
I was trying to do that inside a Doc ...
I m able to get a pointer to the view from the CMyApp
but not from CMyDoc..
what Im trying to do is to to access the pointer to the "device context" of the MyView(CFormView) from MyDoc (CDocument) ...
|
|
|
|
|
Loooser wrote:
I was trying to do that inside a Doc ...
I m able to get a pointer to the view from the CMyApp
but not from CMyDoc..
Do you mean that the GetNextView( GetFirstViewPosition() ) method calls i mentionned above failed, or that you couldn't find a member pointer to the view (or a function like GetActiveView())?
Loooser wrote:
what Im trying to do is to to access the pointer to the "device context" of the MyView(CFormView) from MyDoc (CDocument) ...
Unless you are currently drawing the view, it probably has no associated device context. But you can create it easily enough by:
CClientDC dc( pView );
This creates a client DC - a device context that allows you to draw to the client area of the view.
Dave
|
|
|
|
|
Your method calls failed,
Unless Imdoing something...here is what I have...
CMyDoc* pDoc = GetDocument();
CMyView* pView = pDoc->GetNextView(&pDoc->GetFirstViewPosition());
and here is the error message
error C2102: '&' requires l-value
|
|
|
|
|
Why do you have the ampersand (&) before the call to GetFirstViewPosition()? That will pass the address of the POSITION to the GetNextView() method, not the POSITION itself. Remove the ampersand and it should work.
Dave
|
|
|
|
|
Tried that ....no luck! 
|
|
|
|
|
CMyDoc* pDoc = GetDocument();
CMyView* pView = pDoc->GetNextView(pDoc->GetFirstViewPosition());
|
|
|
|
|
CMyDoc* pDoc = GetDocument();
CMyView* pView = (CMyView *)pDoc->GetNextView(pDoc->GetFirstViewPosition());
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
