From: Julian Smart Date: Sat, 21 Nov 1998 15:40:35 +0000 (+0000) Subject: Doc updates (debug stuff); Cygwin corrections X-Git-Url: https://git.saurik.com/wxWidgets.git/commitdiff_plain/6b037754f53cc35e177bf6787bace26c7cecc6e1 Doc updates (debug stuff); Cygwin corrections git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@1015 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775 --- diff --git a/docs/latex/wx/body.tex b/docs/latex/wx/body.tex index 0379856c00..741e1b61be 100644 --- a/docs/latex/wx/body.tex +++ b/docs/latex/wx/body.tex @@ -728,7 +728,7 @@ Use .wrc (wxWindows resource files) where possible, because they can be easily c independently of source code. Bitmap resources can be set up to load different kinds of bitmap depending on platform (see the section on resource files). -\section{Strategies for debugging} +\section{Strategies for debugging}\label{debugstrategies} \subsection{Positive thinking} @@ -757,49 +757,35 @@ to go from functioning to non-functioning state. This should give a clue to the problem. In some cases though, such as memory leaks or wrong deallocation, this can still give totally spurious results! -\subsection{Genetic mutation} - -If we had sophisticated genetic algorithm tools that could be applied -to programming, we could use them. Until then, a common -- if rather irrational -- -technique is to just make arbitrary changes to the code until something -different happens. You may have an intuition why a change will make a difference; -otherwise, just try altering the order of code, comment lines out, anything -to get over an impasse. Obviously, this is usually a last resort. - \subsection{Use a debugger} This sounds like facetious advice, but it's surprising how often people don't use a debugger. Often it's an overhead to install or learn how to use a debugger, but it really is essential for anything but the most -trivial programs. Some platforms don't allow for debugging, such -as WIN32s under Windows 3.x. In this case, you might be advised to -debug under 16-bit Windows and when you're confident, compile for -WIN32s. In fact WIN32s can be very strict about bad memory handling, -so testing out under WIN32s is a good thing to do even if you're -not going to distribute this version. (Unless you've got a good memory checking, -utility, of course!) Tracking bugs under WIN32s can involve a lot of debug message -insertion and relinking, so make sure your compiler has a fast linker -(e.g. Watcom, Symantec). - -\subsection{Use tracing code} - -You can use wxDebugMsg statements (or the wxDebugStreamBuf class) to -output to a debugging window such as DBWIN under Windows, or standard -error under X. If compiling in DEBUG mode, you can use TRACE statements -that will be compiled out of the final build of your application. +trivial programs. + +\subsection{Use logging functions} + +There is a variety of logging functions that you can use in your program: +see \helpref{Logging functions}{logfunctions}. Using tracing statements may be more convenient than using the debugger in some circumstances (such as when your debugger doesn't support a lot of debugging code, or you wish to print a bunch of variables). -\subsection{Use wxObject::Dump and the wxDebugContext class} +\subsection{Use the wxWindows debugging facilities} + +You can use wxDebugContext to check for +memory leaks and corrupt memory: in fact in debugging mode, wxWindows will +automatically check for memory leaks at the end of the program if wxWindows is suitably +configured. Depending on the operating system and compiler, more or less +specific information about the problem will be logged. -It's good practice to implement the Dump member function for all -classes derived from wxObject. You can then make use of wxDebugContext -to dump out information on all objects in the program, if DEBUG is -defined to be more than zero. You can use wxDebugContext to check for -memory leaks and corrupt memory. See the debugging topic in the -reference manual for more information. +You should also use \helpref{debug macros}{debugmacros} as part of a `defensive programming' strategy, +scattering wxASSERTs liberally to test for problems in your code as early as possible. Forward thinking +will save a surprising amount of time in the long run. + +See the \helpref{debugging overview}{debuggingoverview} for further information. \subsection{Check Windows debug messages} @@ -812,3 +798,14 @@ more problems. However, I doubt it's worth the hassle for most applications. wxWindows is designed to minimize the possibility of such errors, but they can still happen occasionally, slipping through unnoticed because they are not severe enough to cause a crash. + +\subsection{Genetic mutation} + +If we had sophisticated genetic algorithm tools that could be applied +to programming, we could use them. Until then, a common -- if rather irrational -- +technique is to just make arbitrary changes to the code until something +different happens. You may have an intuition why a change will make a difference; +otherwise, just try altering the order of code, comment lines out, anything +to get over an impasse. Obviously, this is usually a last resort. + + diff --git a/docs/latex/wx/category.tex b/docs/latex/wx/category.tex index 768597cf0b..aaf0037bcc 100644 --- a/docs/latex/wx/category.tex +++ b/docs/latex/wx/category.tex @@ -189,6 +189,8 @@ An event object contains information about a specific event. Event handlers {\large {\bf Validators}} +\overview{Overview}{validatoroverview} + These are the window validators, used for filtering and validating user input. @@ -241,10 +243,11 @@ wxWindows supports some aspects of debugging an application through classes, functions and macros. \begin{twocollist}\itemsep=0pt -\twocolitem{\helpref{wxDebugContext}{wxdebugcontext}}{Provides various debugging facilities} +\twocolitem{\helpref{wxDebugContext}{wxdebugcontext}}{Provides memory-checking facilities} %\twocolitem{\helpref{wxDebugStreamBuf}{wxdebugstreambuf}}{A stream buffer writing to the debug stream} \twocolitem{\helpref{wxLog}{wxlog}}{Logging facility} \twocolitem{\helpref{Log functions}{logfunctions}}{Error and warning logging functions} +\twocolitem{\helpref{Debugging macros}{debugmacros}}{Debug macros for assertion and checking} %\twocolitem{\helpref{wxTrace}{wxtrace}}{Tracing facility} %\twocolitem{\helpref{wxTraceLevel}{wxtracelevel}}{Tracing facility with levels} \twocolitem{\helpref{WXDEBUG\_NEW}{debugnew}}{Use this macro to give further debugging information} diff --git a/docs/latex/wx/helpinst.tex b/docs/latex/wx/helpinst.tex index c51a4017ae..050aefdd2f 100644 --- a/docs/latex/wx/helpinst.tex +++ b/docs/latex/wx/helpinst.tex @@ -13,8 +13,9 @@ when it starts, and immediately call {\bf Initialize}\rtfsp to associate a filename with it. The help viewer will only get run, however, just before the first call to display something. -Although all classes actually derive from wxHelpControllerBase, the -appropriate class is aliased to wxHelpController for each platform. +Although all help controller classes actually derive from wxHelpControllerBase and have +names of the form wxXXXHelpController, the +appropriate class is aliased to the name wxHelpController for each platform. There are currently the following help controller classes defined: diff --git a/docs/latex/wx/layalgor.tex b/docs/latex/wx/layalgor.tex index bd5846854c..870a5c1273 100644 --- a/docs/latex/wx/layalgor.tex +++ b/docs/latex/wx/layalgor.tex @@ -40,7 +40,7 @@ bottom of the remaining client area. This scheme implies that order of window cr Say you wish to have an extra toolbar at the top of the frame, a project window to the left of the MDI client window, and an output window above the status bar. You should therefore create the windows in this order: toolbar, output window, project window. This ensures that the toolbar and -output window take up space at the top and bottom, then the remaining height in between is used for +output window take up space at the top and bottom, and then the remaining height inbetween is used for the project window. wxLayoutAlgorithm is quite independent of the way in which diff --git a/docs/latex/wx/sashevt.tex b/docs/latex/wx/sashevt.tex index 379628c5e6..b3b02eec3f 100644 --- a/docs/latex/wx/sashevt.tex +++ b/docs/latex/wx/sashevt.tex @@ -51,8 +51,7 @@ drag was OK or out of the current allowed range. \wxheading{See also} -\helpref{wxWindow::OnSash}{wxwindowonactivate},\rtfsp -\helpref{wxApp::OnSash}{wxapponactivate},\rtfsp +\helpref{wxSashWindow}{wxsashwindow},\rtfsp \helpref{Event handling overview}{eventhandlingoverview} \latexignore{\rtfignore{\wxheading{Members}}} diff --git a/docs/latex/wx/tdebug.tex b/docs/latex/wx/tdebug.tex index e996ebdfb2..76ab37d3db 100644 --- a/docs/latex/wx/tdebug.tex +++ b/docs/latex/wx/tdebug.tex @@ -1,56 +1,84 @@ \section{Debugging overview}\label{debuggingoverview} -Classes: \helpref{wxDebugContext}{wxdebugcontext}, \helpref{wxDebugStreamBuf}{wxdebugstreambuf}, -\rtfsp\helpref{wxObject}{wxobject} +Classes, functions and macros: \helpref{wxDebugContext}{wxdebugcontext}, \helpref{wxObject}{wxobject}, \helpref{wxLog}{wxlog}, +\rtfsp\helpref{Log functions}{logfunctions}, \helpref{Debug macros}{debugmacros} Various classes, functions and macros are provided in wxWindows to help you debug your application. Most of these are only available if you compile both wxWindows, -your application and {\it all} libraries that use wxWindows with the DEBUG flag -set to 1 or more. +your application and {\it all} libraries that use wxWindows with the \_\_WXDEBUG\_\_ symbol +defined. You can also test the \_\_WXDEBUG\_\_ symbol in your own applications to execute +code that should be active only in debug mode. -wxDebugContext is a class that never gets instantiated, but ties together -various functions and variables. It allows you to set the debugging stream, dump -all objects to that stream, write statistics about object allocation, and -check memory for errors. +\wxheading{wxDebugContext} -You can use the \helpref{WXTRACE}{trace} macro to output debugging information in DEBUG mode; -it will be defined to nothing for non-debugging code. +\helpref{wxDebugContext}{wxdebugcontext} is a class that never gets instantiated, but ties together +various static functions and variables. It allows you to dump all objects to that stream, write statistics about object allocation, and +check memory for errors. -It is good practice to define a Dump member function for each class you derive -from a wxWindows class, so that wxDebugContext::Dump can call it and +It is good practice to define a \helpref{wxObject::Dump}{wxobjectdump} member function for each class you derive +from a wxWindows class, so that \helpref{wxDebugContext::Dump}{wxdebugcontextdump} can call it and give valuable information about the state of the application. +If you have difficulty tracking down a memory leak, recompile +in debugging mode and call \helpref{wxDebugContext::Dump}{wxdebugcontextdump} and \helpref{wxDebugContext::PrintStatistics}{wxdebugcontextprintstatistics} at +appropriate places. They will tell you what objects have not yet been +deleted, and what kinds of object they are. In fact, in debug mode wxWindows will automatically +detect memory leaks when your application is about to exit, and if there are any leaks, +will give you information about the problem. (How much information depends on the operating system +and compiler -- some systems don't allow all memory logging to be enabled). See the +memcheck sample for example of usage. + For wxDebugContext to do its work, the {\it new} and {\it delete}\rtfsp operators for wxObject have been redefined to store extra information about dynamically allocated objects (but not statically declared objects). This slows down a debugging version of an application, but can -in theory find difficult-to-detect memory leaks (objects are not +find difficult-to-detect memory leaks (objects are not deallocated), overwrites (writing past the end of your object) and underwrites (writing to memory in front of the object). -If you have difficulty tracking down a memory leak, recompile -in debugging mode and call wxDebugContext::Dump and wxDebugContext::Statistics -at appropriate places. They will tell you what objects have not yet been -deleted, and what kinds of object they are. +If debugging mode is on and the symbol wxUSE\_GLOBAL\_MEMORY\_OPERATORS is set +to 1 in setup.h, 'new' is defined to be: + +{\small +\begin{verbatim} +#define new new(__FILE__,__LINE__) +\end{verbatim} +}% -If you use the macro WXDEBUG\_NEW instead of the normal 'new', the debugging -output (and error messages reporting memory problems) will also tell you what -file and on what line you allocated the object. +All occurrences of 'new' in wxWindows and your own application will use +the overridden form of the operator with two extra arguments. This means that the debugging +output (and error messages reporting memory problems) will tell you what +file and on what line you allocated the object. Unfortunately not all +compilers allow this definition to work properly, but most do. -To avoid the need for replacing existing new operators with WXDEBUG\_NEW, you -can write this at the top of each application file: +\wxheading{Debug macros} +You should also use \helpref{debug macros}{debugmacros} as part of a `defensive programming' strategy, +scattering wxASSERTs liberally to test for problems in your code as early as possible. Forward thinking +will save a surprising amount of time in the long run. + +\helpref{wxASSERT}{wxassert} is used to pop up an error message box when a condition +is not true. You can also use \helpref{wxASSERT\_MSG}{wxassertmsg} to supply your +own helpful error message. For example: + +{\small \begin{verbatim} -#define new WXDEBUG\_NEW + void MyClass::MyFunction(wxObject* object) + { + wxASSERT_MSG( (object != NULL), "object should not be NULL in MyFunction!" ); + + ... + }; \end{verbatim} +} + +The message box allows you to continue execution or abort the program. If you are running +the application inside a debugger, you will be able to see exactly where the problem was. -In non-debugging mode, this will revert to the usual interpretation -of new. Note that for this not to mess up new-based allocation of non-wxObject derived classes and -built-in types, there are global definitions of new and delete which match -the syntax required for storing filename and line numbers. These merely -call malloc and free, and so do not do anything interesting. The definitions -may possibly cause multiple symbol problems for some compilers and so might -need to be omitted by setting the USE\_GLOBAL\_MEMORY\_OPERATORS to 0 in wx\_setup.h +\wxheading{Logging functions} + +You can use the \helpref{wxLogDebug}{wxlogdebug} and \helpref{wxLogTrace}{wxlogtrace} functions to output debugging information in debug mode; +it will do nothing for non-debugging code. \subsection{wxDebugContext overview}\label{wxdebugcontextoverview} @@ -59,8 +87,7 @@ need to be omitted by setting the USE\_GLOBAL\_MEMORY\_OPERATORS to 0 in wx\_set Class: \helpref{wxDebugContext}{wxdebugcontext} wxDebugContext is a class for performing various debugging and memory tracing -operations. wxDebugContext, and the related macros and function WXTRACE and -wxTrace, are only present if USE\_DEBUG\_CONTEXT is used. +operations. This class has only static data and function members, and there should be no instances. Probably the most useful members are SetFile (for directing output @@ -70,35 +97,26 @@ Dump (for dumping the dynamically allocated objects) and PrintStatistics Check to check memory blocks for integrity. Here's an example of use. The SetCheckpoint ensures that only the -allocations done after the checkpoint will be dumped. Unfortunately -the define of new to WXDEBUG\_NEW does not work for Borland C++ (and -perhaps other compilers) because it fails to find the correct overloaded -operator for non-object usage of new. Instead, you need to use WXDEBUG\_NEW -explicitly if there are any examples of non-object new usage in the file. +allocations done after the checkpoint will be dumped. \begin{verbatim} -#define new WXDEBUG_NEW - wxDebugContext::SetCheckpoint(); wxDebugContext::SetFile("c:\\temp\\debug.log"); wxString *thing = new wxString; - // Proves that defining 'new' to be 'WXDEBUG_NEW' doesn't mess up - // non-object allocation. Doesn't work for Borland C++. char *ordinaryNonObject = new char[1000]; wxDebugContext::Dump(); wxDebugContext::PrintStatistics(); \end{verbatim} -You can use wxDebugContext if DEBUG is 1 or more, or you can use it -at any other time (if USE\_DEBUG\_CONTEXT is 1). It is not disabled -for DEBUG = 1 (as in earlier versions of wxWindows) because you -may not wish to recompile wxWindows and your entire application -just to make use of the error logging facility. This is especially -true in a Windows NT or Windows 95 environment, where you cannot -easily output to a debug window: wxDebugContext can be used to -write to log files instead. +You can use wxDebugContext if \_\_WXDEBUG\_\_ is defined, or you can use it +at any other time (if wxUSE\_DEBUG\_CONTEXT is set to 1 in setup.h). It is not disabled +in non-debug mode because you may not wish to recompile wxWindows and your entire application +just to make use of the error logging facility. + +Note: wxDebugContext::SetFile has a problem at present, so use the default stream instead. +Eventually the logging will be done through the wxLog facilities instead. diff --git a/docs/latex/wx/truntime.tex b/docs/latex/wx/truntime.tex index 2d1da9c021..b6c9e8e746 100644 --- a/docs/latex/wx/truntime.tex +++ b/docs/latex/wx/truntime.tex @@ -8,10 +8,13 @@ Another is that instances of a class cannot be created just by knowing the name which makes facilities such as persistent storage hard to implement. Most C++ GUI frameworks overcome these limitations by means of a set of -macros and functions and wxWindows (from version 1.62) is no exception. +macros and functions and wxWindows is no exception. Each class that you wish to be known the type system should have a macro such as DECLARE\_DYNAMIC\_CLASS just inside the class declaration. The macro IMPLEMENT\_DYNAMIC\_CLASS should be in the implementation file. +Note that these are entirely optional; use them if you wish to check object +types, or create instances of classes using the class name. However, +it is good to get into the habit of adding these macros for all classes. Variations on these \helpref{macros}{macros} are used for multiple inheritance, and abstract classes that cannot be instantiated dynamically or otherwise. diff --git a/include/wx/memory.h b/include/wx/memory.h index 0afeaf4ebd..9cfff090e0 100644 --- a/include/wx/memory.h +++ b/include/wx/memory.h @@ -41,19 +41,14 @@ #ifdef __WXDEBUG__ -// #ifndef WXDEBUG_NEW -// #define WXDEBUG_NEW new(__FILE__,__LINE__) -// #endif - void * wxDebugAlloc(size_t size, char * fileName, int lineNum, bool isObject, bool isVect = FALSE); void wxDebugFree(void * buf, bool isVect = FALSE); // Global versions of the new and delete operators. -// Currently, these merely call malloc and free; only the wxObject -// operators do something interesting. But this allows WXDEBUG_NEW to -// work for all 'new's in a file. #if wxUSE_GLOBAL_MEMORY_OPERATORS +// Undefine temporarily (new is #defined in object.h) because we want to +// declare some new operators. #ifdef new #undef new #endif @@ -264,14 +259,14 @@ private: static bool m_checkPrevious; }; -// Output a debug mess., in a system dependent fashion. +// Output a debug message, in a system dependent fashion. void WXDLLEXPORT wxTrace(const char *fmt ...); void WXDLLEXPORT wxTraceLevel(int level, const char *fmt ...); #define WXTRACE wxTrace #define WXTRACELEVEL wxTraceLevel -#else // else part for the #if WXDEBUG +#else // else part for the #if __WXDEBUG__ inline void wxTrace(const char *WXUNUSED(fmt)) {} inline void wxTraceLevel(int WXUNUSED(level), const char *WXUNUSED(fmt)) {} diff --git a/include/wx/object.h b/include/wx/object.h index 027d557aef..f56d1fd41f 100644 --- a/include/wx/object.h +++ b/include/wx/object.h @@ -247,6 +247,7 @@ private: }; #if defined(__WXDEBUG__) && wxUSE_GLOBAL_MEMORY_OPERATORS +// JACS: not necessary now that new can be defined globally //#ifndef WXDEBUG_NEW //#define WXDEBUG_NEW new(__FILE__,__LINE__) //#endif diff --git a/samples/memcheck/memcheck.cpp b/samples/memcheck/memcheck.cpp index 44f024be6b..65d1cbf235 100644 --- a/samples/memcheck/memcheck.cpp +++ b/samples/memcheck/memcheck.cpp @@ -31,8 +31,8 @@ #include "mondrian.xpm" #endif -#if !WXDEBUG -#error You must set WXDEBUG to 1 on the 'make' command line (MSW) or with configure (GTK) +#ifndef __WXDEBUG__ +#error This program must be compiled in debug mode. #endif // Define a new application type @@ -82,7 +82,7 @@ bool MyApp::OnInit(void) frame->Show(TRUE); wxDebugContext::SetCheckpoint(); - wxDebugContext::SetFile("debug.log"); +// wxDebugContext::SetFile("debug.log"); wxString *thing = new wxString; wxDate* date = new wxDate; @@ -96,7 +96,7 @@ bool MyApp::OnInit(void) wxDebugContext::Dump(); wxDebugContext::PrintStatistics(); - // Don't delete these two objects, to force wxApp to flag a memory leak. + // Don't delete these objects, to force wxApp to flag a memory leak. // delete thing; // delete date; // delete[] ordinaryNonObject; diff --git a/src/common/filefn.cpp b/src/common/filefn.cpp index 9f61baf66d..84c0a65c36 100644 --- a/src/common/filefn.cpp +++ b/src/common/filefn.cpp @@ -55,12 +55,6 @@ #ifdef __GNUWIN32__ #include -// #include - -#ifndef __MINGW32__ -#include -#endif - #define stricmp strcasecmp #endif @@ -214,11 +208,18 @@ wxString wxPathList::FindAbsoluteValidPath (const wxString& file) bool wxFileExists (const wxString& filename) { +#ifdef __GNUWIN32__ // (fix a B20 bug) + if (GetFileAttributes(filename) == 0xFFFFFFFF) + return FALSE; + else + return TRUE; +#else struct stat stbuf; if (filename && stat ((char *)(const char *)filename, &stbuf) == 0) return TRUE; return FALSE; +#endif } /* Vadim's alternative implementation diff --git a/src/makeg95.env b/src/makeg95.env index 56230fadc7..83f77c93c8 100644 --- a/src/makeg95.env +++ b/src/makeg95.env @@ -39,8 +39,8 @@ MAKE=make LEX=flex.exe -t -L # YACC. byacc or bison -YACC=byacc.exe -# YACC=bison.exe +# YACC=byacc.exe +YACC=bison.exe # Resource compiler RESCOMP=windres.exe @@ -57,15 +57,6 @@ OPTIONS= # -D__MINGW32__ # -D__EGCS__ # IRIX: -g3 DEBUGFLAGS = -ggdb -D__WXDEBUG__ -# Debug/trace mode. 1 or more for memory debugging. -# Unfortunately this doesn't seem to work with GnuWin32 - get warning: -# ../../include/wx/memory.h:58: warning: declaration of `operator delete(void *)' -# throws different exceptions -# :58: warning: previous declaration here -# So setting to 0 for now. - -WXDEBUG=0 - WIN95=1 ifeq ($(WIN95),0) @@ -143,8 +134,8 @@ LDLIBS = $(LIBS) OBJDIR = objects$(GUISUFFIX) # You shouldn't need to change these... -CPPFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUGFLAGS) -DWXDEBUG='$(WXDEBUG)' $(WARN) $(OPT) -CFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUGFLAGS) -DWXDEBUG='$(WXDEBUG)' $(WARN) $(OPT) +CPPFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUGFLAGS) $(WARN) $(OPT) +CFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUGFLAGS) $(WARN) $(OPT) LDFLAGS = -Wl,--subsystem,windows -mwindows -L$(WXDIR)/lib .SUFFIXES: .rc .$(RESSUFF) .$(RSCSUFF) .cpp .c diff --git a/src/motif/utilsexc.cpp b/src/motif/utilsexc.cpp index 4a1c2709e0..a47a394130 100644 --- a/src/motif/utilsexc.cpp +++ b/src/motif/utilsexc.cpp @@ -51,7 +51,21 @@ #endif +#ifdef __SVR4__ + #include +#endif + +#ifdef __SOLARIS__ +// somehow missing from sys/wait.h but in the system's docs +extern "C" +{ + pid_t wait4(pid_t pid, int *statusp, int options, struct rusage + *rusage); +} +#endif + #include +#include #include @@ -82,7 +96,7 @@ void xt_notify_end_process(XtPointer client, int *fid, /* wait4 is not part of any standard, use at own risk * not sure what wait4 does, but wait3 seems to be closest, whats a digit ;-) * --- offer@sgi.com */ -#if !defined(__sgi) +#if !defined(__sgi) && !defined(__ALPHA__) wait4(process_data->pid, NULL, 0, NULL); #else wait3((int *) NULL, 0, (rusage *) NULL); diff --git a/src/msw/makefile.g95 b/src/msw/makefile.g95 index a1cbd58329..b98ea796ee 100644 --- a/src/msw/makefile.g95 +++ b/src/msw/makefile.g95 @@ -64,7 +64,6 @@ GENERICOBJS= \ $(GENDIR)/colrdlgg.$(OBJSUFF) \ $(GENDIR)/fontdlgg.$(OBJSUFF) \ $(GENDIR)/gridg.$(OBJSUFF) \ - $(GENDIR)/helpxlp.$(OBJSUFF) \ $(GENDIR)/laywin.$(OBJSUFF) \ $(GENDIR)/msgdlgg.$(OBJSUFF) \ $(GENDIR)/panelg.$(OBJSUFF) \ @@ -124,19 +123,22 @@ COMMONOBJS = \ $(COMMDIR)/datstrm.$(OBJSUFF) \ $(COMMDIR)/objstrm.$(OBJSUFF) \ $(COMMDIR)/extended.$(OBJSUFF) \ + $(COMMDIR)/socket.$(OBJSUFF) \ + $(COMMDIR)/sckaddr.$(OBJSUFF) \ + $(COMMDIR)/sckfile.$(OBJSUFF) \ + $(COMMDIR)/sckipc.$(OBJSUFF) \ + $(COMMDIR)/sckstrm.$(OBJSUFF) \ + $(COMMDIR)/protocol.$(OBJSUFF) \ + $(COMMDIR)/http.$(OBJSUFF) \ + $(COMMDIR)/ftp.$(OBJSUFF) \ + $(COMMDIR)/url.$(OBJSUFF) \ $(COMMDIR)/wincmn.$(OBJSUFF) -# Unfortunately, GnuWin32 fails with a syntax error in Sockets.h, -# so remove socket code. -# $(COMMDIR)/socket.$(OBJSUFF) \ -# $(COMMDIR)/sckaddr.$(OBJSUFF) \ -# $(COMMDIR)/sckfile.$(OBJSUFF) \ -# $(COMMDIR)/sckipc.$(OBJSUFF) \ -# $(COMMDIR)/sckstrm.$(OBJSUFF) \ -# $(COMMDIR)/protocol.$(OBJSUFF) \ -# $(COMMDIR)/http.$(OBJSUFF) \ -# $(COMMDIR)/ftp.$(OBJSUFF) \ -# $(COMMDIR)/url.$(OBJSUFF) \ +# This must be renamed! It conflicts with the g++ fstream.h. +# $(COMMDIR)/fstream.$(OBJSUFF) \ + +# NOTE: if the socket-related files above fail with a syntax error in Sockets.h, +# remove the files (probably all GnuWin32 releases < b20). MSWOBJS = \ accel.$(OBJSUFF) \ diff --git a/src/msw/registry.cpp b/src/msw/registry.cpp index 114169fad1..ef80ce3c23 100644 --- a/src/msw/registry.cpp +++ b/src/msw/registry.cpp @@ -194,7 +194,7 @@ wxRegKey::wxRegKey() wxRegKey::wxRegKey(const wxString& strKey) : m_strKey(strKey) { m_hRootKey = (WXHKEY) aStdKeys[ExtractKeyName(m_strKey)].hkey; - m_hKey = NULL; + m_hKey = (WXHKEY) NULL; m_dwLastError = 0; } @@ -203,7 +203,7 @@ wxRegKey::wxRegKey(StdKey keyParent, const wxString& strKey) : m_strKey(strKey) { RemoveTrailingSeparator(m_strKey); m_hRootKey = (WXHKEY) aStdKeys[keyParent].hkey; - m_hKey = NULL; + m_hKey = (WXHKEY) NULL; m_dwLastError = 0; } @@ -221,7 +221,7 @@ wxRegKey::wxRegKey(const wxRegKey& keyParent, const wxString& strKey) RemoveTrailingSeparator(m_strKey); m_hRootKey = keyParent.m_hRootKey; - m_hKey = NULL; + m_hKey = (WXHKEY) NULL; m_dwLastError = 0; } @@ -562,7 +562,7 @@ wxRegKey::ValueType wxRegKey::GetValueType(const char *szValue) bool wxRegKey::SetValue(const char *szValue, long lValue) { if ( CONST_CAST Open() ) { - m_dwLastError = RegSetValueEx((HKEY) m_hKey, szValue, RESERVED, REG_DWORD, + m_dwLastError = RegSetValueEx((HKEY) m_hKey, szValue, (DWORD) RESERVED, REG_DWORD, (RegString)&lValue, sizeof(lValue)); if ( m_dwLastError == ERROR_SUCCESS ) return TRUE; @@ -640,7 +640,7 @@ bool wxRegKey::SetValue(const char *szValue, const wxString& strValue) { if ( CONST_CAST Open() ) { #ifdef __WIN32__ - m_dwLastError = RegSetValueEx((HKEY) m_hKey, szValue, RESERVED, REG_SZ, + m_dwLastError = RegSetValueEx((HKEY) m_hKey, szValue, (DWORD) RESERVED, REG_SZ, (RegString)strValue.c_str(), strValue.Len() + 1); if ( m_dwLastError == ERROR_SUCCESS ) diff --git a/src/msw/treectrl.cpp b/src/msw/treectrl.cpp index 42b81f0760..6b4b2317b5 100644 --- a/src/msw/treectrl.cpp +++ b/src/msw/treectrl.cpp @@ -467,7 +467,7 @@ wxTreeItemId wxTreeCtrl::DoInsertItem(const wxTreeItemId& parent, mask |= TVIF_IMAGE; tvIns.item.iImage = image; - if ( selectedImage = -1 ) + if ( selectedImage == -1 ) { // take the same image for selected icon if not specified selectedImage = image; diff --git a/src/msw/utilsexc.cpp b/src/msw/utilsexc.cpp index 43e66153a2..aae349314d 100644 --- a/src/msw/utilsexc.cpp +++ b/src/msw/utilsexc.cpp @@ -40,10 +40,6 @@ #ifdef __GNUWIN32__ #include #include -#ifndef __MINGW32__ -#include -#endif - #endif #ifdef __WIN32__ diff --git a/utils/wxprop/src/propform.cpp b/utils/wxprop/src/propform.cpp index e0fc064ba1..8dd42a4ef4 100644 --- a/utils/wxprop/src/propform.cpp +++ b/utils/wxprop/src/propform.cpp @@ -187,6 +187,7 @@ void wxPropertyFormView::OnOk(wxCommandEvent& WXUNUSED(event)) return; sm_dialogCancelled = FALSE; + TransferToPropertySheet(); m_managedWindow->Close(TRUE); } @@ -204,7 +205,8 @@ void wxPropertyFormView::OnHelp(wxCommandEvent& WXUNUSED(event)) void wxPropertyFormView::OnUpdate(wxCommandEvent& WXUNUSED(event)) { - TransferToPropertySheet(); + if (Check()) + TransferToPropertySheet(); } void wxPropertyFormView::OnRevert(wxCommandEvent& WXUNUSED(event))