From: Maurizio G. <MJ...@mc...> - 2004-10-05 08:46:27
|
Hello, I've installed mingw 3.1.0 recently. When I've tried to compile old programs I've got many errors like this: invalid conversion from `void*' to `HWND__*' (referring to HDC wndDC; wndDC=3DGetDC(hw);) I've never seen this error using older releases... how can avoid this (without adding (TYPE) before command I mean)? Another small question: how can I include .res files in the executable? I used rsrc -o file.exe file.res ... Thank you in advance Maurizio |
From: John G. <jo...@jo...> - 2004-10-05 17:31:49
|
Maurizio Galeone wrote: > I've installed mingw 3.1.0 recently. > When I've tried to compile old programs > I've got many errors like this: Could you please post a short code sample illustrating the problem? I think I know the cause but I need to be sure. -- John Gaughan http://www.johngaughan.net/ jo...@jo... |
From: Maurizio <MJ...@mc...> - 2004-10-05 20:32:09
|
Hello, and thanx for answering. > Could you please post a short code sample illustrating the problem? I > think I know the cause but I need to be sure. mm_snapview.h:42: invalid conversion from `void*' to `HWND__*' mm_snapview.h:44: invalid conversion from `void*' to `HWND__*' HANDLE h; WIN32_FIND_DATA fd; HDC wndDC; HBITMAP hbmp=NULL; *type=0; if ((h=FindFirstFile(fn,&fd))!=INVALID_HANDLE_VALUE) { if (lstrcmpi(fd.cFileName+lstrlen(fd.cFileName)-3,"png")==0) { p2d->structsize=sizeof(PNGD_P2DINFO); p2d->flags=0; p2d->pngfn=fd.cFileName; if (!read_png_to_dib(p2d)) { 42 wndDC=GetDC(hw); ERROR HERE hbmp=CreateDIBitmap(wndDC,p2d->lpdib,CBM_INIT,p2d->bits,(LPBITMAPINFO)p2d->lpdib,DIB_RGB_COLORS); 44 ReleaseDC(hw,wndDC); ERROR HERE *type=2; } FindClose(h); } else if ............ ******************** AND ALSO ******************** mm_preferences.h:154: invalid conversion from `void*' to `HBRUSH__*' HBRUSH hbrush; HDC hdc; OPENFILENAME ofn; char temp[MAX_PATH]; char fn[MAX_PATH]; RECT raux; switch (iMessage) { case WM_CTLCOLORSTATIC: 154 hbrush=GetStockObject(BLACK_BRUSH); ERROR HERE Thank you. Maurizio |
From: Luke D. <cod...@ho...> - 2004-10-06 01:51:20
|
Does it help if you #define NO_STRICT in your source code before #including windows.h? Luke ----- Original Message ----- From: "Maurizio" <MJ...@mc...> To: <min...@li...> Sent: Wednesday, October 06, 2004 4:32 AM Subject: Re: [Mingw-users] [NEWBIE] invalid conversion > Hello, and thanx for answering. > > > Could you please post a short code sample illustrating the problem? I > > think I know the cause but I need to be sure. > > mm_snapview.h:42: invalid conversion from `void*' to `HWND__*' > mm_snapview.h:44: invalid conversion from `void*' to `HWND__*' > > HANDLE h; > WIN32_FIND_DATA fd; > HDC wndDC; > HBITMAP hbmp=NULL; > *type=0; > if ((h=FindFirstFile(fn,&fd))!=INVALID_HANDLE_VALUE) > { > if (lstrcmpi(fd.cFileName+lstrlen(fd.cFileName)-3,"png")==0) > { > p2d->structsize=sizeof(PNGD_P2DINFO); > p2d->flags=0; > p2d->pngfn=fd.cFileName; > if (!read_png_to_dib(p2d)) > { > 42 wndDC=GetDC(hw); ERROR HERE > hbmp=CreateDIBitmap(wndDC,p2d->lpdib,CBM_INIT,p2d->bits,(LPBITMAPINFO)p2d->l pdib,DIB_RGB_COLORS); > 44 ReleaseDC(hw,wndDC); ERROR HERE > *type=2; > } > FindClose(h); > } > else if ............ > > ******************** > > AND ALSO > > ******************** > > mm_preferences.h:154: invalid conversion from `void*' to `HBRUSH__*' > > HBRUSH hbrush; > HDC hdc; > OPENFILENAME ofn; > char temp[MAX_PATH]; > char fn[MAX_PATH]; > RECT raux; > switch (iMessage) > { > case WM_CTLCOLORSTATIC: > 154 hbrush=GetStockObject(BLACK_BRUSH); ERROR HERE > > Thank you. > > Maurizio |
From: Maurizio <MJ...@mc...> - 2004-10-06 16:38:05
|
> Does it help if you #define NO_STRICT in your source code before > #including > windows.h? nope :-( |
From: Maurizio <MJ...@mc...> - 2004-10-07 17:51:06
|
> Does it help if you #define NO_STRICT in your source code before > #including > windows.h? HEY.. NOW IT WORKS!!!!! thanx to everyone of you, friends!!!! Best regards. Maurizio Galeone |
From: John G. <jo...@jo...> - 2004-10-06 03:58:54
|
Maurizio wrote: > 42 wndDC=GetDC(hw); ERROR HERE I assume "hw" is of type HWND? I see nothing wrong with your code, and just as a sanity check, I wrote similar code and tried compiling it. It worked as expected. You mention MinGW 3.1.0, the installer. It is over a year old. I recommend updating all the individual packages to newer version. It is easy -- just download the components you need, then unzip them into your main MinGW directory preserving subdirectories. This may or may not solve this issue, but it will not hurt. If nothing else, download the latest Windows API package and try that. A few months after that package was made, the MinGW team released a new one with a whole bunch of bug fixes and improvements. -- John Gaughan http://www.johngaughan.net/ jo...@jo... |
From: Maurizio <MJ...@mc...> - 2004-10-07 11:07:07
|
> I assume "hw" is of type HWND? I see nothing wrong with your code, and > just as a sanity check, I wrote similar code and tried compiling it. It > worked as expected. > > You mention MinGW 3.1.0, the installer. It is over a year old. I > recommend updating all the individual packages to newer version. It is > easy -- just download the components you need, then unzip them into your > main MinGW directory preserving subdirectories. This may or may not > solve this issue, but it will not hurt. > > If nothing else, download the latest Windows API package and try that. A > few months after that package was made, the MinGW team released a new > one with a whole bunch of bug fixes and improvements. I've tried, but the error appears again. I've found this: http://www.massey.ac.nz/~mgwalker/misc/createthread.html Maybe there's the solution... but I don't think I've understood :-( How should I correct my code????? thanx |
From: Greg C. <chi...@mi...> - 2004-10-07 12:37:44
|
On 2004-10-07 7:08 AM, Maurizio wrote: [John Gaughan wrote:] >> I assume "hw" is of type HWND? I see nothing wrong with your code, and >> just as a sanity check, I wrote similar code and tried compiling it. >> It worked as expected. > > I've tried, but the error appears again. The only way to resolve this is to post a minimal, self-contained test case that exhibits the problem. You had posted > mm_preferences.h:154: invalid conversion from `void*' to `HBRUSH__*' (good: cut and paste exact error messages) > HBRUSH hbrush; > HDC hdc; > OPENFILENAME ofn; > char temp[MAX_PATH]; > char fn[MAX_PATH]; > RECT raux; > switch (iMessage) > { > case WM_CTLCOLORSTATIC: > 154 hbrush=GetStockObject(BLACK_BRUSH); ERROR HERE but that's not minimal (many of the declarations aren't used) or self-contained (every line depends on something defined in some header, but we don't know what headers you included). Probably it'll be enough to say #include [what?] HBRUSH hbrush; hbrush=GetStockObject(BLACK_BRUSH); |
From: John G. <jo...@jo...> - 2004-10-06 03:50:07
|
Maurizio Galeone wrote: > Another small question: > how can I include .res files > in the executable? > I used > rsrc -o file.exe file.res rsrc? What is that? Are you trying to compile resources? windres input.res -o output.o -- John Gaughan http://www.johngaughan.net/ jo...@jo... |
From: Maurizio <MJ...@mc...> - 2004-10-08 17:35:08
|
> windres input.res -o output.o I've tried to compile resources in many different ways.. this one does NOT seem to work. Can you post some on-topic examples please? Thanx Maurizio |
From: Greg C. <chi...@mi...> - 2004-10-08 22:20:23
|
On 2004-10-08 1:36 PM, Maurizio wrote: >> windres input.res -o output.o > > I've tried to compile resources in many different ways.. > this one does NOT seem to work. > > Can you post some on-topic examples please? Rather than construct a teaching example, I'll grab one from the real world. Here's something I copied from makefile output and reformatted for readability. It's actual production stuff, so it's been well tested and it certainly works, though it's not exemplary. "C:/gcc-2.95.2-1/bin/windres" --include-dir C:/unified/src --include-dir C:/unified/src/ming29521 --include-dir C:/boost/boost_1_23_0 --include-dir C:/msys/1.0/local/include/libxml2 --include-dir C:/owl/gcc/win32api/include --include-dir C:/owl/include --include-dir C:/unified/src --define GNU_WINDRES --define WINVER=0x0400 --use-temp-file -I rc -O coff C:/unified/src/ihs_resources.rc -o ihs_resources.rc.o The relevant parts of the makefile look like this for MinGW: # TRICKY !! '-i' is ambiguous: # for windres, it means 'input file' # for borland, it means 'include path' RC_INPUT_FILE_INDICATOR := -i # windres has an anomalous syntax: # -I means 'input format', while 'include' is --include-dir # 'define symbol' is not -D, but rather --define # # We explicitly define GNU_WINDRES so that we can write conditional sections # in the resource file. # # Specialized gcc make-inc files must define $(comp_includes). gcc_generic_rcflags = \ $(subst -I,--include-dir ,$(comp_includes)) \ --include-dir $(src_dir) \ --define GNU_WINDRES \ --define WINVER=0x0400 \ --use-temp-file \ -I rc \ -O coff \ [omit complex definition of $(comp_includes)] comp_rcflags = $(gcc_generic_rcflags) ALL_RCFLAGS = $(comp_rcflags) $(ALLCPPFLAGS) %.rc.o: %.rc $(MAKEDEPEND) $(RC) $(ALL_RCFLAGS) $(RC_INPUT_FILE_INDICATOR) $< -o $@ which explains why boost libraries are exposed to the resource compiler: it's just a harmless accident. Hmmm...dunno why $(RC_INPUT_FILE_INDICATOR) doesn't show up. I guess '-i' is assumed. I'll have to fix that. |
From: Maurizio <MJ...@mc...> - 2004-10-09 10:40:13
|
> Here's something I copied from makefile output and reformatted > for readability. It's actual production stuff, so it's been > well tested and it certainly works, though it's not exemplary. thanx, but that stuff wasn't understandable for me.... What about a very low-level example? I just have to compile a simple .res file into an executable one... I used this command: rsrc -o mamemix.exe mamemix.res taken from this package http://www.mathematik.uni-bielefeld.de/~rainer/ thank you again |
From: Greg C. <chi...@mi...> - 2004-10-09 13:02:41
|
On 2004-10-09 6:41 AM, Maurizio wrote: >> Here's something I copied from makefile output and reformatted >> for readability. It's actual production stuff, so it's been >> well tested and it certainly works, though it's not exemplary. > > thanx, but that stuff wasn't understandable for me.... > What about a very low-level example? Think of resource files as source files in a special language. You use the compiler to translate C or C++ source files into object files, which typically have suffix '.o': gcc foo.c --> foo.o g++ foo.cpp --> foo.o The object files are intermediate files that you can't usefully edit and can't run. Instead, you pass them to the linker. Similarly, you use 'windres' to translate resource source files into an intermediate form suitable for linking. Typically, the source files have suffix '.rc' and the intermediate files have suffix '.res': windres foo.rc --> foo.res The linker works with the intermediate files. To combine these files into an executable file: [linker-name] -o foo.exe foo.o foo.res The linker has its own name, but you normally don't use it directly. It's more convenient to say 'gcc' for C or 'g++' for C++: they invoke the linker and tell it what standard libraries to link. So in practice you'd write: gcc -o foo.exe foo.o foo.res if foo.o was C, or g++ -o foo.exe foo.o foo.res if foo.o was C++. You just pass the '.res' file to the linker like any other object file. > I just have to compile a simple .res file into an executable one... I would guess that this '.res' file has already been compiled. (If you examine it, it's probably not easily readable by a human.) Try linking it, as above, with your other compiled object files. If that doesn't work, get the original source file (probably 'mamemix.rc') and compile it with 'windres', then proceed as above. > I used this command: > rsrc -o mamemix.exe mamemix.res I don't recognize 'rsrc' as part of the MinGW distribution. Perhaps it's a third-party program that appends resources to a program that's already been linked. I'm not aware of any MinGW program that does that. |
From: John G. <jo...@jo...> - 2004-10-09 15:41:39
|
Greg Chicares wrote: > Similarly, you use 'windres' to translate resource source files > into an intermediate form suitable for linking. Typically, the > source files have suffix '.rc' and the intermediate files have > suffix '.res': I always compiled .rc files to an intermediate file with with a .o extension. I suppose the linker does not care, but is this the "right" way to compile resource files? I.e., we typically name C++ files with a .cpp or .cc extension, will it confuse people if I compile resources to .o as opposed to .res? > I don't recognize 'rsrc' as part of the MinGW distribution. Neither do I. The only thing I can think of is the OP has a non-standard distribution, maybe with a third-party resource compiler or another utility added in. Thank you for explaining this so well. I tried to explain it a day or two ago while being concise, giving the short version, and the OP apparently thought I addressed a different question. -- John Gaughan http://www.johngaughan.net/ jo...@jo... |
From: Greg C. <chi...@mi...> - 2004-10-09 17:06:21
|
On 2004-10-09 11:40 AM, John Gaughan wrote: > Greg Chicares wrote: > >> Similarly, you use 'windres' to translate resource source files >> into an intermediate form suitable for linking. Typically, the >> source files have suffix '.rc' and the intermediate files have >> suffix '.res': > > I always compiled .rc files to an intermediate file with with a .o > extension. Personally, I'm using '.rc.o' [more on that below], but I like your plain '.o' convention better. This works with borland tools as well. > I suppose the linker does not care, but is this the "right" > way to compile resource files? One school of thought uses .obj for compiled source .res for compiled resources \Program Files as the one true place to put binaries I don't belong to that school, so I don't use '.res' myself. I wrote '.res' in that example because it seemed to be the convention the OP was using. If 'windres' by default appends '.res', then that might be an argument in favor of it. OTOH, writing rm *.o seems easier than rm *.o *.res > I.e., we typically name C++ files with a > .cpp or .cc extension, will it confuse people if I compile resources to > .o as opposed to .res? wxWidgets just uses plain '.o', at least with MinGW. I use '.rc.o' simply because I once had foo.cpp foo.rc and needed to disambiguate them. I now wish I hadn't done that--after all, you wouldn't name source files like this: foo.cpp foo.c It seems better in retrospect to make the name stems differ: foo.cpp foo_resources.rc Because I didn't do that, I wasted time on the following regrettable workaround for autodependencies: # 20030504 GWC changed command option # -M # to # -M -MT $@ \ # for the gcc-3.x+ preprocessor. Tested with gcc-3.2.3, but not with # any earlier 3.x version. # # Purpose: to overcome a change in preprocessor behavior between # gcc-2.95x and gcc-3.x that had caused a problem in situations like: # # .SUFFIXES: # %.rc.o : %.rc # $(MAKEDEPEND) # $(RC) $(ALL_RCFLAGS) $< -o $@ # # 2.95 # $/gcc-2.95.2-1/bin/cpp --version # 2.95.2 # $/gcc-2.95.2-1/bin/cpp -M resource.rc # resource.rc.o: resource.rc header.hpp # Note the 'rc' in target name 'resource.rc.o'... # # 3.2.3 # $/MinGW/bin/cpp --version # cpp.EXE (GCC) 3.2.3 (mingw special 20030425-1) [...] # $/MinGW/bin/cpp -M resource.rc # resource.o: resource.rc header.hpp # Oops, no more 'rc' in target name # # $/MinGW/bin/cpp -MT resource.rc.o -M resource.rc # resource.rc.o: resource.rc header.hpp # 3.x specific, but it works. # # With this modification, the gcc-2.95.2-1 preprocessor reports # 'unrecognized option' for '-MT', which seems benign, but the # following filename may cause grief--so we use '-MT' only with # the gcc-3.x preprocessor. Now it looks like I was thinking too hard that day. |
From: John G. <jo...@jo...> - 2004-10-10 04:18:41
|
Greg Chicares wrote: > Now it looks like I was thinking too hard that day. Welcome to my world, at least according to my wife :-) I always make sure the base filename is different between compilation units. I do not have a "foo.cpp" and "foo.rc" file in any project I make. I typically call the resource file something like "resource.rc" so there is no confusion, especially since I only need one resource file per project. Of course, maybe this makes too much sense, maybe I am planning ahead too well ;-) -- John Gaughan http://www.johngaughan.net/ jo...@jo... |
From: Luke D. <cod...@ho...> - 2004-10-11 02:32:55
|
----- Original Message ----- From: "Greg Chicares" <chi...@mi...> To: <min...@li...> Sent: Sunday, October 10, 2004 1:05 AM Subject: Re: [Mingw-users] [NEWBIE] invalid conversion > On 2004-10-09 11:40 AM, John Gaughan wrote: > > > Greg Chicares wrote: > > > >> Similarly, you use 'windres' to translate resource source files > >> into an intermediate form suitable for linking. Typically, the > >> source files have suffix '.rc' and the intermediate files have > >> suffix '.res': > > > > I always compiled .rc files to an intermediate file with with a .o > > extension. > > Personally, I'm using '.rc.o' [more on that below], but > I like your plain '.o' convention better. > > This works with borland tools as well. > > > I suppose the linker does not care, but is this the "right" > > way to compile resource files? > > One school of thought uses > .obj for compiled source > .res for compiled resources > \Program Files as the one true place to put binaries > > I don't belong to that school, so I don't use '.res' myself. > I wrote '.res' in that example because it seemed to be the > convention the OP was using. The problem that it simply won't work. The ".res" extension is used for "binary resource files" which are the output format of the MS resource compiler but which is different to the COFF object file format. While windres and the MS linker support .res files the GNU linker does not, which is why the OP is having trouble now. By default windres determines the output format by the filename extension so you really should use ".rc.o" or just ".o" (unfortunately I have seen some makefiles that generate COFF files with the ".res" extension). Luke |
From: Maurizio <MJ...@mc...> - 2004-10-09 16:20:10
|
> gcc -o foo.exe foo.o foo.res what went wrong? C:\MMW>windres mamemix.rc -o mamemix.res C:\MMW>compila C:\MMW>gcc -I./zlib -I./lpng -O -c -o mamemix.o mamemix.c C:\\MMW>mingw32-make all gcc -o mamemix -I./lpng -I./zlib -O mamemix.o pngdib.o mamemix.res -L./lpng/ -L. /zlib/ -lpng -lz -lm -mwindows -lcomctl32 -lcomdlg32 -luser32 -lgdi32 mamemix.res: file not recognized: File format not recognized mingw32-make: *** [all] Error 1 Thanx |
From: Maurizio <MJ...@mc...> - 2004-10-10 11:05:05
|
> gcc -o foo.exe foo.o foo.res nope... I used: windres foo.rc foo_res.o gcc -o foo.exe foo.o foo_res.o and now everything works fine :-) AT LAST!!!!! :-P Thanx for your help Maurizio |
From: Danny S. <dan...@cl...> - 2004-10-08 23:49:04
|
Greg Chicares wrote: > > # windres has an anomalous syntax: > # -I means 'input format', while 'include' is --include-dir > # 'define symbol' is not -D, but rather --define This has changed in new windres. From binutils.info:: `-J FORMAT' `--input-format FORMAT' The input format to read. FORMAT may be `res', `rc', or `coff'. If no input format is specified, `windres' will guess, as described above. <snip> `-I DIRECTORY' `--include-dir DIRECTORY' Specify an include directory to use when reading an `rc' file. `windres' will pass this to the preprocessor as an `-I' option. `windres' will also search this directory when looking for files named in the `rc' file. If the argument passed to this command matches any of the supported FORMATS (as descrived in the `-J' option), it will issue a deprecation warning, and behave just like the `-J' option. New programs should not use this behaviour. If a directory happens to match a FORMAT, simple prefix it with `./' to disable the backward compatibility. `-D TARGET' `--define SYM[=VAL]' Specify a `-D' option to pass to the preprocessor when reading an `rc' file. `-U TARGET' `--undefine SYM' Specify a `-U' option to pass to the preprocessor when reading an `rc' file. < snip> > Hmmm...dunno why $(RC_INPUT_FILE_INDICATOR) doesn't > show up. I guess '-i' is assumed. I'll have to fix that. > `-i FILENAME' `--input FILENAME' The name of the input file. If this option is not used, then `windres' will use the first non-option argument as the input file name. If there are no non-option arguments, then `windres' will read from standard input. `windres' can not read a COFF file from standard input. Danny > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on > ITManagersJournal Use IT products in your business? Tell us what you > think of them. Give us Your Opinions, Get Free ThinkGeek Gift > Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |