|
http://i.imgur.com/mkoBXWc.jpg
please check out the image
|
|
|
|
|
That is as a good as sending a picture of your care and saying "it won't start".
|
|
|
|
|
http://i.imgur.com/vO4uFTL.jpg
Look at this error message DO I have any mistake by using enum ? i guess ?
|
|
|
|
|
Don't you have and compiler ? Why don't you just compile and debug the code ?
|
|
|
|
|
Member 12035138 wrote: Why don't you just compile and debug the code ? Why don't you? Seriously, this site is here to help when you have problems, but it is up to you to gather the correct information. We cannot do everyone's work for them.
|
|
|
|
|
I shared the code and error message what else you need ? If you cant help just tell type here it's not big deal
|
|
|
|
|
Member 12035138 wrote: what else you need ? I have told you more than once what we need. Create a proper debug version of your code, then run it in the debugger in order to gather proper information.
|
|
|
|
|
The error is probably here:
uniform_int_distribution < int > passNumberDist(1000000, 99999);
The first distribution parameter should be less than the second.
|
|
|
|
|
Thank you I solved the compiler error !
|
|
|
|
|
FYI - I have found and reported a bug with std::unique_ptr when used in code built with /clr in VS 2015.
Consider this code:
void accept_ownership( std::unique_ptr<MyClass> ptr ) { ... }
void test() {
std::unique_ptr<MyClass> mc = std::make_unique<MyClass>( args );
accept_ownership( std::move(mc) );
}
When accept_ownership is called in C++/CLI code, mc will be destructed and accept_ownership receives a unique_ptr pointing to freed memory. There will be a double-free at exit as well.
I've reported the bug with send-a-frown and it is NOT fixed in the Update 1 RC. Let's hope it's fixed in Update 1 RTM.
The code works as expected when not built with /clr.
John
|
|
|
|
|
Message Closed
modified 4-Nov-15 13:58pm.
|
|
|
|
|
As a warmup for a more complex project in C#, I have started to code a C++/CLI library to allow simple access of C# applications to features of DirectWrite. (I am aware that there are such helper libraries already out there but I was not able yet to get them to work with in Visual Studio 2015 and with Windows 10.)
So far so good. A first test run showed the text in the target window but not as I would have expected for ClearType display. A screenshot of the displayed text can be found here.
My understanding of the relating MSDN documentation is that ClearType is enabled by default. The title bar text of the window is obviously set up with text in ClearType. I guess I missed a setting in the DWrite factory but I do not know which.
Does anybody have an advice for me?
|
|
|
|
|
It looks like your coordinates are being calculated incorrectly and you are not leaving enough space between lines of text.
|
|
|
|
|
Thank you for your response. You had indeed a good idea but I am afraid that this is not likely the reason:
- You can see from the screenshot, the character 'g' is shown completely where other characters like the adjacent are not shown completely.
- The text has been sent to DX as one single block, without the explicit specification of leading. I would assume then that DX selects a sufficient leading.
Meanwhile, I have made several more tests with my application but I have not found a way yet to improve the text display. However, I do not give up. ClearType works well on my computer; any application - except mine - is using it successfully.
I have collected my little test in a ZIP file which can be loaded from this location. I am currently using Windows 10 and Visual Studio Community 2015.
|
|
|
|
|
|
I had downloaded that example yesterday - It's really HUGE! And - unfortunately - it fails to build. I am receiving error message "C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(2048,5): error MSB3774: Could not find SDK "Microsoft.VCLibs, Version=14.0".".
There are several comments about this issue in the net but only very few solution proposals. I tried one and ran the repair of my Visual Studio but the building problem remained.
I will now start to work myself through the code and try to find answers to my specific problem. That will take a while since I do not know if the problem is caused by any System or VS settings or just by my code.
|
|
|
|
|
Some of the members here are quite selective about which forums they visit, and it's quite possible that the people who would maybe know the answer never come here. Your problem has nothing to do with C++/CLI but is about DirectX, so a question in the Graphics forum may catch someone's eye. You could also try a search of the Articles section to see if anyone has written about it.
|
|
|
|
|
Hi Richard,
That is a real good point. You are right: DirectWrite is much more a matter of Graphics. The C++/CLI issues in my problem are secondary.
Thank you for this advice.
|
|
|
|
|
I have had a look at your code (I am not able to build it). I wonder if you need to adjust your line spacing based on the actual size of the created font, rather than the requested size.
|
|
|
|
|
I built your project and played with it a bit but was not able to eliminate the issue. I consulted some of our DX code and things are very similar. We do create a DC render target instead of an HWND render target and set the flags to be GDI compatible but everything else looks similar. Our content is hosted within a WPF window so that's another difference.
Is this a high-DPI issue by chance? I run at 125% and didn't try your app at 100% (96 dpi). Perhaps some sizes need to be scaled differently.
I see that things stretch as the window is resized. So perhaps the drawing is extra compressed which causes the bitmap to be resampled?
Sorry I'm not much more help. I certainly feel your pain though.
John
|
|
|
|
|
I have now tested with several different font sizes. Looks ok at 36pt. Real bad result at 12pt: Even the two lines of text (rendered as one single text block) seem to have different sizes, see screenshot. This is definitively not ClearType.
I guess now I missed somewhere to enable ClearType and will give a close look to the sample Richard MacCutchan indicated to me.
Stretching of the text block upon resizing of the window is an undesired effect caused by the very simple design of the test, should be done better in a 'real' application.
|
|
|
|
|
I have also tried to switch from 100% to 125% -- same result (25% larger than in previous test, and my desktop got 'reorganized' by Windows). Gone back to 100%
|
|
|
|
|
Meanwhile, I have modified the test to a sole C++ application, and Ido still get the same (non-ClearType like) result. I am reposting this in the Graphics forum.
|
|
|
|
|
Hi Guys,
I am getting flicker while painting a border on control, bannerbar(its derived from CWnd only). So the case if control is getting focus , border should get paint otherwise not.
I am handling OnsetFocus and OnKillfocus and calling Paintborder() in which I checked if banner got focus(by checking m_BannerHasFocus flag) i will call parent->InavlidateRect() here i passed banner rect as argument.
In Onpaint I am taking PS_DOT pen (if its have focus) and PS_NULL if don' have focus.
I am getting flicker while its getting/loosing focus Even i pass FALSE parameter in InvalidateRect, which will not erase background.
Please help me out. I pasted source code here. Thanks
void CBannerBar::OnSetFocus(CWnd* pOldWnd)
{
CBaseWnd::OnSetFocus(pOldWnd);
// TODO: Add your message handler code here
m_BannerHasFocus = true;
PaintBannerBorder();
}
void CBannerBar::OnKillFocus(CWnd* pNewWnd)
{
CBaseWnd::OnKillFocus(pNewWnd);
// TODO: Add your message handler code here
m_BannerHasFocus = false;
PaintBannerBorder();
}
void CBannerBar::PaintBannerBorder()
{
//Invalidate the control in order to hide the focus rectangle.
CRect rect;
GetWindowRect(&rect);
CWnd* pParent = GetParent();
if (!rect.IsRectEmpty() && pParent != NULL)
{
pParent->ScreenToClient(rect);
pParent->InvalidateRect(rect, FALSE);
}
}
void CBannerBar::OnPaint()
{
CPaintDC dc(this); // device context for painting
// create a brush of the background color and paint the window with it
CBrush brush (BACK_COLOR);
dc.FillRect(&dc.m_ps.rcPaint, &brush);
brush.DeleteObject();
CDC* pDC = GetWindowDC();
CRect rect;
GetWindowRect(&rect);
rect.OffsetRect(-rect.left, -rect.top);
COLORREF dColour = GetSysColor(COLOR_HIGHLIGHT);
if (m_BannerHasFocus)
{
dColour = RGB(255, 0, 0);
}
CPen pen(m_BannerHasFocus ? PS_DOT : PS_NULL, 1, dColour);
CPen* penOld = (CPen*)pDC->SelectObject(&pen);
pDC->SetBkMode(TRANSPARENT);
pDC->MoveTo(rect.left, rect.top);
pDC->LineTo(rect.right - 1, rect.top);
pDC->LineTo(rect.right - 1, rect.bottom - 1);
pDC->LineTo(rect.left, rect.bottom - 1);
pDC->LineTo(rect.left, rect.top);
pDC->SelectObject(penOld);
ReleaseDC(pDC);
// Do not call CBaseWnd::OnPaint() for painting messages
}
|
|
|
|
|
You may want to try this in the C / C++ / MFC forum. This is C++ / CLI.
|
|
|
|