|
Please check out the image below
http://i.imgur.com/NeaItgZ.jpg
|
|
|
|
|
Very interesting; what does it mean?
|
|
|
|
|
|
If you really want help with this issue then please do what I suggested in my first response.
|
|
|
|
|
I have attached the image please check out and let me know what you need
|
|
|
|
|
I mean you need to run your program under the debugger to trap exactly where the error occurs, what the error is, and what variables, pointers etc. are possibly causing the fault. Without that information it is impossible to guess what may be going wrong.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
