yang686526

1.14.02 bug?
1.14.02 bug?
i am creating two devices just like odamfcapp. one is the primary device, the other is an overlay device. the primary device is created with:
windowhdc, clearscreen (true), doublebufferenabled(true), enablesoftwarehlr(true), discardbackfaces(true). the overlay with: windowhdc, clearscreen (false), doublebufferenabled(false). the primary device will draw appropriately. the overlay doesn't. if i comment out the primary draw then i can get the overlay to draw. has oda changed how it works with double buffering? our code works nicely with 1.14.01, but i can't get both device to draw at the same time in 1.14.02 . obviously, something has changed in the hdc management code inside oda. i've looked carefully at odamfc for clues but there really is no difference in the way we create/use the devices. however, we are using our own threading model so its not easy to try exactly what odamfcapp does. i've been through the changes to the header signatures for the new code and there aren't any smoking guns there either.
george,
sorry about the double post. i am sure its 1.14.2 and wingdi.gs related. are you keeping the hdc around for each device? we are calling invalidate and update for each device (the primary and highlight devices). i've noticed that when i only have the highlight device turned on (clearscreen (false), doublebufferenabled(false)) i get a resource leak of some sort. my createcompatibledc eventually fails and all hell breaks loose. i have tried a ton of variations and i can't get any of them to work. please elaborate on the double buffering scheme your utilizing.
i just discovered the source code -- and i have found the bug! it is in the exgsscreendevice code. what was happening was we were passing both the hdc and hwnd.
code:

void createcontext()
{
if(m_hwnd && !m_hdc)
m_hdc = ::getdc(m_hwnd);
if(!m_hdc)
throw oderror(enotinitializedyet);
m_ncolordepth = getdevicecolordepth();
t::createcontext();
}
void deletecontext()
{
t::deletecontext();
if (m_hdc && m_hwnd)
{
::releasedc(m_hwnd, m_hdc);
m_hdc = null;
}
}
note that the ::getdc is not called if the m_hdc is passed in...but ::releasedc is called regardless. hence the nasty surprise i experienced. if you want to reproduce in odamfc app just pass the hwnd and hdc into the device's dictionary props.
i forgot all the devices were in the source code; it would have saved me a couple of days of insanity.
thanks,
tyler
george,
thats how i fixed it too. i also had to fix one other bug associated with the compatibledc living the span of the device; onsize must update the size of the compatibledc's bitmap. to reproduce: start with a smaller app window and resize to a larger one. oda neat draws onto the originally size device context because the bitmap is not resized.
thanks,
tyler
still can not resize window
tyler,
i did apply both fixes to the code. still can not resize singledoc sample: window keeps all background in new area.
could you, please, give more directions how to fix it?
life would be so much easier if we could just look at the source codefff">fff">
i'm having the same problem with singledoc
is there a solution for this problem? i verified that my code has all these fixes, yet singledoc still does not repaint properly when the window size goes beyond a certain point. when i size smaller, it generally works.
i also applied the fixes from the dwgdirect.zip in a later post.