Re: wxWidgets 2.9 build

On Wed, Jan 19, 2011 at 6:04 PM, Peter Geoghegan
<peter(dot)geoghegan86(at)gmail(dot)com> wrote:
> I decided to copy the OGL headers into /include/wx/ogl and proceed
> with getting the remaining translation units to compile, where
> compilation was completely aborted before due to ogl.h not being
> available. I've posted to wx users, and to bakefile-devel, and will
> hopefully have a solution to my linker problem soon. I've written my
> own little wrapper function for Scintilla encoding functions that will
> be temporarily used as a drop in replacement for wx2stc(). There is no
> standard header that I can include for the Scintilla stuff (2
> functions originally declared in UniConversion.h), so I've written
> some extern declarations myself. I realise that this isn't acceptable
> for production, but I think it's silly to worry about it until I can
> actually run the code through a debugger  (i.e. the eventual
> implementation that uses Wx utilities only).

OK.

> Now, all object files compiled, except where we have Bison/Flex problems.

:-(

> I have attached a patch for your information. Obviously, I am not
> asking you to commit it. Most warnings have been fixed - I didn't fix
> one in gqbGridPanel::OnButtonUp(wxCommandEvent&) where I think we
> downcast with a C style cast.

Hmm, I didn't spot anything in there that looked horrendously
objectional. The "foo.c_str()" -> "(const char *) foo" changes are
somewhat ugly though

> I think I found a bug in pgRole.cpp at line 304, where we compared a
> long to a wxString. Obviously wxString's newfound stronger typing
> highlighted this. Comparing strings of OIDs instead ought to be safe,
> right?

Oops. Yep, that should be fine.

> Not quite sure how to proceed with bringing sqlGridBoolEditor (which
> inherits from wxGridCellEditor) up to speed with 2.9, but that should
> be clearer when I can debug. changes.txt says
> "wxGridCellEditor::EndEdit() signature has changed and it was split in
> two functions, one still called EndEdit() and ApplyEdit() (both are
> pure, and ApplyEdit has no actual implementation). See the
> documentation of the new functions for more details about how grid
> editors should be written now". The docs say of AppyEdit()
> "Effectively save the changes in the grid. This function should save
> the value of the control in the grid. It is called only after
> EndEdit() returns true."

I assume, just move:

grid->GetTable()->SetValue(row, col, value);

into ApplyEdit() ?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company