For those new to message boards please try to follow a few simple rules when posting your question.
Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
Keep the subject line brief, but descriptive. eg "File Serialization problem"
Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode HTML tags when pasting" checkbox before pasting anything inside the PRE block, and make sure "Ignore HTML tags in this message" check box is unchecked.
Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
No advertising or soliciting.
We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
That looks wrong. That looks like your compiler command could be boiled down to
g++ CTEST.o -o CTEST.o
You're passing in and producing the same .o file, not creating an executable, only an intermediate object. In which case the g++ warning makes sense, since its telling you that the lib wasn't used to create the .o file. In which case you should be getting a g++ fatal error input file is same as output file.
Second thing is the warning itself. The path given is /usr/lib/x86_64-linux-gnu/bluetooth. Normally that would be libbluetooth.a. In which case the linker should be able to pick it up as -lbluetooth, since its in the expected location. It just doesn't have a name format that the linker recognizes as a library. I'd say say something messed up when installing the library, if this is indeed the case and you've not just messed up copying the output from your system to the forum.
I am posting this here because I hope the actual output will help to solve the issue , and it is not small!
I have an app using bluetooth - linked to library "bluetooth". It works fine.
I need to identify the actual type of library ( Linux .a or .so ).
GCC options do not require prefix, such as "lib." or suffix - .a or .so thus GCC output cannot tell me the library file full name.
I also need the (-L) path to the library and GCC does not correlate -L with -l.
try ldd myprog. If the library shows up in the output, then it is dynamically linked, e.g. a .so library. If it doesn't, then its a static library (.a).
Usually the linker (ld, not gcc), will prefer the dynamic library over the static, so the resulting executable will a) use new versions of the library, if it gets updated, and b) (less important these days) have a smaller on-disk footprint. If you are linking to the .so and you want to force the linker to use the static library you can do that with the following options to gcc
-Wl,-Bstatic -lsome_lib -Wl,-Bdynamic
If you don't add the -Wl,-Bdynamic at the end, then libc gets statically linked in, too, which is probably not what you want. Of course you could just pass -static to gcc for the final linking stage, and that will produced a static binary (no shared libs), which should run on most linux boxes of with the same architecture (e.g X86 or ARM). I say most, because if you compiled on say Ubuntu 18.04, and tried to run on something ancient, like maybe RedHat 9 (shrike), you would probably get a execution error.
But it would be helpful to know why you want to know this. Normally, we don't care whether we're linking to a dynamic or static library, just as long as the program works. Your question suggests to me that you're bumping up against an issue and are trying to force the OS into doing what you think it should, rather than working with the OS
I read some articles on how to make a win32 prog DPI aware. I want to make a dialog which has
windows controls, bitmaps and gdiplus objects combined.
I am using VS2019 and started a MFC app from scratch.
What would be the right way to get a DPI aware app, because I set DPI to high in the MFC app setting and used GetDeviceCaps to draw the lines. But when DPI is set to HIGH the lines do not match with the controls anymore. When I switch it off, the graphics look blurry, but are on the right position.
I made some screenshots to show what I mean:
Thanks, but that didnt answer my question. How should I draw Gdiplus graphics and controls so that they are always drawn correctly (same position) on all Dpi settings?
The code that I use can be seen in the first screenshot.
Short answer you scale everything long answer you scale everything
Okay to get scale factor you need the DPI of the screen which you use Win32 API
HDC Dc = GetDC(GetDesktopWindow()); // Get Screen DC
int DpiX = GetDeviceCaps(Dc, LOGPIXELSX); // X DPI for this DC (96 for normal screen)
int DpiY = GetDeviceCaps(Dc, LOGPIXELSY); // Y DPI for this DC (96 for normal screen)
ReleaseDC(GetDesktopWindow(), Dc); // Release screen DC finished with it now
if (DpiX != 96 || DpiY != 96) // High DPI mode active
/* calculate scale */
double ScaleX = (double)DpiX/96;
double ScaleY = (double)DpiY/96;
Thanks for your reply. I already tried to calculate the coord with GetDeviceCaps, but that does not work correctly! When I set 150% font size in windows I get a ratio of 144/96=1.5 as expected, but the controls and the dialog itself do not scale that way!
Here a different example:
I have drawn two red rectangles, one with the size of the dialog and an inner one which is the size of a group box. For the size of the dialog rectangle I use GetClientRect. It works on all font sizes (DPI scalings) correct.
For the inner rectangle inside the group box I tried to recalculate the coords with GetDeviceCaps, but that does not work. If I change scaling in windows the inner rectangle is completely off.
So I tried to figure out the correct coords for the inner rectangle by trial and error. Below are the coords which draw the correct rectangles in relation to the group box.
But how can I calculate them, I get some weird values? In the x axis I would get a factor of 1.3328 and on the y axis a factor of 1.62 with 150% scaling, not 1.5 as expected!?
You are obviously loading the dialog from a resource file or template.
Those have a normal DPI scale of 48 and yes it gets messy.
1.) Don't do it .... manually create the dialog and insert the items.
2.) If you don't want to do it manually on window entries that draw on the WM_CREATE grab the size and scale of the window just like you did. Which is basically what Gerry is saying below and contain your draws to windows. That means if you want to draw something on the dialog background make an transparent invisible window in the resource so it scales with the rest of the dialog and draw on it.
You are sort of creating a mountain out of a molehill.
Thanks for your replies. I drew the controls with the MFC resource editor, so the scaling doesnt match as you said.
So, I started a Win32 desktop application from scratch without MFC or other wrappers. I will do all drawings and scalings myself for all elements. I hope this will solve my DPI problems. I know that this is much work, but I only have experience with VisualStudio and MFC and I have to learn the basic WIN32 stuff first. I wanted to know the underlying win32 basics anyway.