see Changelog

Author: Koen Deforche

Changelog

@@ -13,6 +13,11 @@
 
 	* WDatePicker.C: implement setEnabled()
 
+	* WT_SERIES, WT_MAJOR, WT_MINOR, WT_VERSION: change to hexadecimal
+	format for preprocessor defines
+
+	* Ext/TableView.C: fix access to null dataStore_
+
 26-03-2009:
 	* Fixed cookie handling. Cookie parser is now less strict, and cookie
 	values are URL encoded, similar to PHP. Fixed setting multiple

WConfig.h.in

@@ -2,9 +2,9 @@
 #define WCONFIG_H
 
 // Version defines
-#define WT_SERIES ${VERSION_SERIES}
-#define WT_MAJOR  ${VERSION_MAJOR}
-#define WT_MINOR  ${VERSION_MINOR}
+#define WT_SERIES 0x${VERSION_SERIES}
+#define WT_MAJOR  0x${VERSION_MAJOR}
+#define WT_MINOR  0x${VERSION_MINOR}
 
 /*! \brief A constant that encodes the library version of %Wt
  *

examples/simplechat/simplechat.xml

@@ -4,17 +4,17 @@
 
 <h2><span>Wt Chat client</span></h2>
 
-<p>This is a simple multi-user chat client and server.</p>
+<p>This is a multi-user chat client and server.</p>
 
-<p>For simplicity, server and client all run in the same process, and
-therefore it is ideal for a deployment using wthttpd, when running all
-clients in the same process. (Because all I/O is asynchroneous, this
-probably could easily support thousands of simultaneous users as
-well).</p>
+<p>To keep the example simple, server and clients all run in the same
+process. Still, because all I/O in Wt is asynchronous even when using
+"server push" which requires an open connection with each client at
+all times, clients do not tie up threads, and as such the application
+could easily support thousands of simultaneous users as well.</p>
 
 <p>The client is contained in a widget (SimpleChatWidget), and can be
 instantiated as many times as you like, even in the same
-application. <br />
+application.<br />
 
 Because of the widget abstraction, it is straight forward to include a
 chat client in your own application, by linking both the client and
@@ -24,10 +24,11 @@ server classes into your application.</p>
   <message id="details">
 
 <p>The implementation uses server-initiated updates, a feature that is
-still under development in Wt. When a message is received, the user
-interface (i.e. widget tree) not only of the current session, but also
-of all other clients is updated simultaneously, as part of handling
-the event.</p>
+not much different from regular client-server communication in Wt, and
+allows updating a session from outside its regular event loop. When a
+message is received, the user interface (i.e. widget tree) not only of
+the current session, but also of all other sessions is updated and
+"pushed" to these clients simultanously.</p>
 
   </message>
 

src/Wt/Ext/NumberField.C

@@ -3,6 +3,7 @@
  *
  * See the LICENSE file for terms of use.
  */
+#include <iomanip>
 #include <boost/lexical_cast.hpp>
 
 #include "Wt/Ext/NumberField"
@@ -20,15 +21,19 @@ NumberField::NumberField(WContainerWidget *parent)
 
 void NumberField::setValue(double value)
 {
-  lineEdit()->setText(boost::lexical_cast<std::string>(value));
+  std::ostringstream oss;
+  oss << std::fixed << std::setprecision(decimals_) << value;
+  lineEdit()->setText(oss.str());
 }
 
 double NumberField::value() const
 {
   try {
     return boost::lexical_cast<double>(lineEdit()->text());
   } catch (boost::bad_lexical_cast& e) {
-    return 0; // FIXME ?
+    // You wouldn't expect this to happen anless a user is tampering
+    // 0 with do in that case
+    return 0;
   }
 }
 

src/Wt/Ext/TableView.C

@@ -409,7 +409,8 @@ void TableView::refresh()
 
 void TableView::updateExt()
 {
-  addUpdateJS(dataStore_->jsGetUpdates(elVar() + ".getStore()"));
+  if (dataStore_)
+    addUpdateJS(dataStore_->jsGetUpdates(elVar() + ".getStore()"));
 
   Panel::updateExt();
 }