I'm trying to handle a trackbar notification, but for some reason my GCC compiler complains that the TRBN_THUMBPOSCHANGING identifier is undeclared.
I have included the header,
#include <commctrl.h>
and initialised the controls,
INITCOMMONCONTROLSEX icex;
icex.dwICC = ICC_LISTVIEW_CLASSES | ICC_WIN95_CLASSES;
InitCommonControlsEx(&icex);
I have also tried ICC_BAR_CLASSES and a few others instead of the win95 one.
Also I'm compiling via bat file including this command
gcc foodplaner.o resources.o sqlite3.o -lgdi32 -lcomctl32 -o foodplaner.exe
Creating the trackbar was no problem, it shows up and can be controlled.
What am I missing?
TRBN_THUMBPOSCHANGING is available in Windows Vista and above. To use it you have to set _WIN32_WINNT to the minimum supported version of your application prior to including any header files. This can be done in code
#define _WIN32_WINNT 0x0600 // Windows Vista
or on your compiler's command line (-D_WIN32_WINNT=0x0600). The latter is recommended to prevent introducing any mismatches. See Using the Windows Headers for details.
Related
I'm new in winAPI and I was learning how code programs with some special functions and such, so I downloaded the Windows's SDK.
Problem is, GCC decided to put the blind glasses and say:
Documents_path.c:6:25: fatal error: KnownFolders.h: No such file or directory
#include<KnownFolders.h>
^
compilation terminated.
I said "OK, next one then" and there's another header with the same problem:
thread.c:3:30: fatal error: processthreadsapi.h: No such file or directory
#include<processthreadsapi.h>
^
compilation terminated.
I checked if these headers are even in my PC and here they are setting with windows.h, which it was working when I tried basic functions with it.
I searched an answer for this problem but didn't find any, either it was a external\binary libraries problem, is it local or not or a macro fix (which it didn't work).
How can I fix the problem?
EDIT:
I'm using VS Code
EDIT2:
This is the code of "Documents_path.c" example:
#include<stdio.h>
#include<stdlib.h>
#include<Windows.h>
#include<ShlObj.h>
#include<initguid.h>
#include<KnownFolders.h>
#pragma comment(lib, "user32.lib")
int main(){
int a;
PWSTR path = NULL;
HRESULT hr = SHGetKnownFolderPath(&FOLDERID_Documents, 0, NULL, &path);
if(SUCCEEDED(hr)){
printf("path for Documents is: %ls", path);
}
scanf("%d",&a);
CoTaskMemFree(path);
return 0;
}
And I'm reading the basics of winAPI from this website:
https://zetcode.com/gui/winapi/
as for structure of project folder:
C:\Users\ %USER%\Documents\C\dawd
MSVC uses Windows SDK while GCC does not.
On Windows GCC uses MinGW or MinGW-w64 as standard library, which is an open source implementation of Windows API.
So GCC+MinGW will use its own headers and will not look for any Windows SDK. So GCC+MinGW on Windows works without having any Microsoft developer tools installed at all.
MinGW-w64 - which is more recent than MinGW and which supports both Windows 32-bit and 64-bit - exists in a standalone package that can be downloaded from https://winlibs.com/. But you can still use it from an IDE like VSCode or Code::Blocks.
MinGW-w64 has the files like knownfolders.h and processthreadsapi.h which you had issues with.
But be aware that #pragma comment(lib, "user32.lib") is MSVC-specific and will not work in other compilers like GCC. Instead you must use linker flag -luser32. Because you call CoTaskMemFree() you will also need to add -lole32.
I tried your code on my system and it compiles and links fine with:
gcc -c -o Documents_path.o Documents_path.c
gcc -o Documents_path.exe Documents_path.o -luser32 -lole32
I am experiencing an issue with O_DIRECT.
I am trying to use it with open(), but I get an error like:
error: O_DIRECT undeclared (first use in this function)
I am including <fcntl.h>
I grepped /usr/include/ directory for O_DIRECT and it exists in x86_64-linux-gnu/bits/fcntl-linux.h. I tried to include this file instead, but then I get this error:
error: #error Never use <x86_64-linux-gnu/bits/fcntl-linux.h> directly; include <fcntl.h> instead.
I am trying to all of this in Eclipse CDT project on newly installed Ubuntu 20.04 system.
You should define _GNU_SOURCE before including <fcntl.h> or add -D_GNU_SOURCE to your compiler command.
Note that this reduces portability of your program.
it exists in x86_64-linux-gnu/bits/fcntl-linux.h. I tried to include this file instead, but then I get this error
As the error says, you shouldn't include bits headers directly.
O_DIRECT is a Linux extension (i.e. not in POSIX). You need to define _GNU_SOURCE to get it. You can either define it at the top of source file, like:
#define _GNU_SOURCE
or define while compiling with -D_GNU_SOURCE. e.g.
gcc -D_GNU_SOURCE file.c
You may interested in What does "#define _GNU_SOURCE" imply? too.
I am using MinGW GCC compiler on Windows 7. I am trying to compile source that contains the following code:
MEMORYSTATUSEX mem_stat;
mem_stat.dwLength = sizeof(memstat);
BOOL success = GlobalMemoryStatusEx(mem_stat);
ram_ptr = &(mem_stat->ullAvailPhys);
As I'm sure you can guess, this code simply gets the available memory using the MEMORYSTATUSEX struct returned by GlobalMemoryStatusEx.
When I try to compile, I get this error:
error: unknown type name 'MEMORYSTATUSEX'
I looked in winbase.h (in the MinGW installation include folder) and guess what I found?
#if (_WIN32_WINNT >= 0x0500)
typedef struct _MEMORYSTATUSEX {
DWORD dwLength;
DWORD dwMemoryLoad;
DWORDLONG ullTotalPhys;
DWORDLONG ullAvailPhys;
DWORDLONG ullTotalPageFile;
DWORDLONG ullAvailPageFile;
DWORDLONG ullTotalVirtual;
DWORDLONG ullAvailVirtual;
DWORDLONG ullAvailExtendedVirtual;
} MEMORYSTATUSEX,*LPMEMORYSTATUSEX;
#endif
So it's there. I'm guessing this has something to do with the precompiler if/endif, but I don't how to fix that....
Also what's even more bizzare is that if I use the MEMORYSTATUS struct instead, it works fine.
According to the MS docs, both have the same minimum client version requirement:
MEMORYSTATUSEX:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366589%28v=vs.85%29.aspx
MEMORYSTATUS:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366772%28v=vs.85%29.aspx
Is there some compiler flag I need to set? Or does anyone have any other solutions?
Thanks in advance for your help!
Before including Windows.h, add :
#define WINVER 0x0500
The header file windef.h says :
/*
* If you need Win32 API features newer the Win95 and WinNT then you must
* define WINVER before including windows.h or any other method of including
* the windef.h header.
*/
and then compile with the -std=c++11 flag like :
g++ -Wall -std=c++11 -c <yourFile>.cpp -o <yourFile>.o
Apparently you have to define _WIN32_WINNT yourself either as a compiler flag or definition statement in one of your header/source files for this particular function to work properly.
Adding the #define _WIN32_WINNT 0x0500 will allow the code to compile normally.
I am trying to compile a simple C Windows API program using the Windows SDK Command Prompt.
Here an excerpt from the program:
#include <Windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
[...]
RegisterClass(&wc);
hwnd = CreateWindow("test", NULL, 0, 0, 0, 0, 0, NULL, NULL, hInstance, NULL);
[...]
When I compile it using
cl test.c
in the Windows SDK Command Promt, it gives me a lot of linker errors like these:
test.obj : error LNK2019: unresolved external symbol __imp_CreateWindowExA referenced in function WinMain
test.obj : error LNK2019: unresolved external symbol __imp_RegisterClassA referenced in function WinMain
There are at least two problems.
The linker is telling you that there is an "unresolved external symbol". That means it can't find a definition for the function(s) that you tried to call. In this case, there are two such undefined functions: CreateWindowExA and RegisterClassA.
Obviously the definition for those functions is not to be found in your code, but rather in the Windows API libraries, so you'll need to inform the linker of where it can find those definitions.
The SDK comes with stubs (*.lib) files, which contain information used by the linker so that it can find the proper function definitions in the Windows DLLs at runtime. You need to instruct the linker where it can find those *.lib files.
There are a couple of different strategies for doing so:
The simple (albeit non-portable) way is to insert a #pragma statement into your source file that instructs the compiler to leave a comment recognized by the linker. For example,
#pragma comment(lib, "user32")
automatically links to user32.lib, which is the stub file for user32.dll.
Alternatively, you can pass the parameters on the command line to cl.exe. This gets awfully complicated in a hurry, though, if you're not using MSBuild or some kind of make file. In this case, you would need to modify your command line to (at minimum):
cl test.c user32.lib
Both of these options naturally assumes that your Windows SDK directory was added to the path. I'm pretty sure the installer does that for you automatically, but I'm not positive. If it doesn't, or you've removed these files from your path, you'll need to use fully-qualified paths to the *.lib files on the command line.
Reading the documentation for the possible compiler options is a good place to start. Or better yet, if you're unfamiliar with Windows programming, using an environment like Visual Studio that puts all of this stuff together for you automatically. Once you understand what's going on, look to see what the command line that Visual Studio runs is, and dissect it bit-by-bit.
Next problem is that you're compiling without Unicode defined, and because ANSI is the default, all of the macros inside the Windows header files are resolving to call the A suffixed versions of all the SDK functions. This is probably not what you want. Windows has been fully Unicode now for over a decade, and all new applications should be built as Unicode. The Unicode versions have a W suffix appended to their name.
Again, you can instruct the compiler to build with Unicode explicitly by either adding lines to your source file, or adding parameters to your command line.
In this case, the simplest way is probably just to add
#define UNICODE
to the top of your source file before #include <windows.h>. Just as we saw above, from the Visual Studio environment, UNICODE is automatically defined for you unless you explicitly change your project settings to target something else.
Those functions live in user32.lib. You need to supply that to the cl tool.
cl test.c ""C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\user32.lib"
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.307
Copyright (C) Microsoft Corporation. All rights reserved.
test.c
Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
/out:test.exe
test.obj
"C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib\user32.lib"
I'm following the tuto:
http://zetcode.com/tutorials/gtktutorial/firstprograms/
It works but each time I double click on the executable,there is a console which I don't want it there.
How do I get rid of that console?
I tried this:
add_executable(Cmd WIN32 cmd.c)
But got this fatal error:
MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain#16 referenced in function ___tmainCRTStartup
Cmd.exe : fatal error LNK1120: 1 unresolved externals
While using gcc directly works:
gcc -o Cmd cmd.c -mwindows ..
I'm guessing it has something to do with the entry function: int main( int argc, char *argv[]),but why gcc works?
How can I make it work with cmake?
UPDATE
Let me paste the source code here for convenience:
#include <gtk/gtk.h>
int main( int argc, char *argv[])
{
GtkWidget *window;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_widget_show(window);
gtk_main();
return 0;
}
UPDATE2
Why gcc -mwindows works but add_executable(Cmd WIN32 cmd.c) not?
Maybe that's not the equivalent for -mwindows in cmake?
add_executable(Cmd WIN32 cmd.c)
Tells CMake this is a Windows program, and it looks for WinMain instead of main. If you want to see the flags being used you can run make VERBOSE=1. The question might be how do you define WinMain for gtk apps? I know with Qt, you link in a library that defines it for you.
You can set these linker flags to have a main() entry point and no console:
SET(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS} /subsystem:windows /ENTRY:mainCRTStartup")
For more info, see this answer for the linker flags, and this answer for how to set flags in cmake.
For CMake 3.13 and newer you can use
target_link_options(target PRIVATE "/SUBSYSTEM:WINDOWS" "/ENTRY:mainCRTStartup")
If you want your program to run in console mode (ie a main function), you have to specify it in your project's properties in MSVC. What you're using right now is a project in windowed mode (ie a WinMain function, which you don't have, hence the error).
But if you don't want to get the ugly console window, you want to use the windowed mode (ie transform your main function into a propper WinMain function). This way your normal window is all that will show.
edit: As an aside, you really shouldn't name your program "cmd", that's the name of Windows' command interpreter.
According to the CMake documentation for using the WIN32 flag with ADD_EXECUTABLE:
When this property is set to true the executable when linked on Windows will be created with a WinMain() entry point instead of of just main().This makes it a GUI executable instead of a console application. See the CMAKE_MFC_FLAG variable documentation to configure use of MFC for WinMain executables.
However, your program's entry point is main() and not WinMain(). What you should do, instead, is omit the WIN32 flag, but you need to link against libgtk. So, you would use TARGET_LINK_LIBRARIES:
FIND_PACKAGE(GTK2 2.6 REQUIRED gtk)
INCLUDE_DIRECTORIES(${GTK2_INCLUDE_DIRS})
LINK_DIRECTORIES(${GTK2_LIBRARIES})
ADD_EXECUTABLE(myprogramname source1 source2 ... sourceN)
TARGET_LINK_LIBRARIES(myprogramname ${GTK2_LIBRARIES})
While the accepted answer works for MinGW, it won't work for MSVC when you don't define a WinMain. No answer is cross-toolchain compatible IMHO.
Fix Subsystem
add_executable(my_exe WIN32 main.c)
basically passes -mwindows if MinGW compiler is used or /SUBSYSTEM:WINDOWS if MSVC. This sets the subsystem field in PE header of the generated executable to 2 i.e. IMAGE_SUBSYSTEM_WINDOWS_GUI. This instructs Windows to not provide a separate console window for this executable.
Fix Entry Point on MSVC
When MSVC receives /SUBSYSTEM:WINDOWS, its runtime expects1 a WinMain, not main, to be defined unlike MinGW's (which works with any one defined). If you want to continue to use main, fix the entry point:
target_link_options(my_exe PRIVATE
$<$<CXX_COMPILER_ID:MSVC>:/ENTRY:mainCRTStartup>
)
1: Yes, OS first calls C runtime and it's the C runtime which calls your executable's entry point
Fix Subsystem Per-config
add_executable(my_exe WIN32 ... internally sets the executable's WIN32_EXECUTABLE property. This gives another, more useful way to do it:
add_executable(my_exe main.c) # look ma, no WIN32!
set_target_properties(my_exe PROPERTIES WIN32_EXECUTABLE 1)
This is useful when you want to do it only for some configurations. I personally enable this only on Release builds, while having a console window on Debug builds is useful.
# No console window for non-debug builds
set_target_properties(my_exe PROPERTIES WIN32_EXECUTABLE
$<AND:$<PLATFORM_ID:Windows>,$<NOT:$<CONFIG:Debug,RelWithDebInfo>>>
)
Verify
# Generate Ninja files for GCC
cmake -B build_g -G "Ninja Multi-Config"
# Generate Visual Studio project and solution for MSVC
cmake -B build_v -G "Visual Studio 17 2022"
# Build with verbosity
cmake --build build_g --config Release -v
This should show the actual build commands with parameters in full verbosity. Useful to verify if -mwindows or /SUBSYSTEM:WINDOWS is passed for the right build configurations.