Further to , Reinhard Müller (reinhard) suggested to James Thompson (jamest) if you are bored, you can try again the wx26 uidriver, as Johannes Vetter (johannesV) had done some massive changes and it might be that your issues with fscking up the boxes are solved. James said that, although he was busy, i really need to get that tested, as the dropdown box issues in 2.4 are preventing some selections from being allowed. So he was keen to have a version of GNUe Forms that worked with the user interface driver for wx 2.6 as soon as possible.

Trying Johannes' new code for GNUe Forms with his existing GNUe Forms Definitions, James found problems - none of which are due to anything wrong with what you've done - it's all in my forms, where he had been relying on 'features' (such as overlapping text boxes) that Johannes had treated as 'bugs' and now fixed. Johannes confirmed that overlaping is now being checked ... not only for boxes but for all widgets. He added, if you click the detail-button you'll see the offending line in your XML-File - this makes debuging a GNUe Form Definition (gfd) a lot easier. James reported that all five of his existing GNUe Form Definitions were not working with the new code - but i would still imagine it's something funky I'm doing in the form rather than a problem with Johannes' code. He noted that, on the last one, the problem that he had been having with the dropdown menu had been fixed, but the form now aborts on query.

Note that the lack of any guarantees on backward compatability, even with 'features'/'bugs' is one of the reasons why GNUe Forms remains at a version number below 1.0 as of time of writing, as discussed further in .

The mext day, Reinhard noticed that dialog boxes in the wx26 driver are not modal - the "go to record" box and the about box both allow the main form to be clicked while the box is still open - then the cursor even blinks in the main form - but I can't type anything. Later, Johannes reported the dialogs *are* shown modal ... i would say it's a bug in wx that the mouse-click is sent to (and handled by) the parent-window. He confirmed that, when using the user interface drivers on Microsoft Windows and Mac OS X, the focus stayed on the dialog box, and correctly ignored any clicks on the parent form. Reinhard wondered if this was a problem specific to the GTK2 desktop he was using under GNU/Linux - I think for gtk2 modal dialogs *always* allow the main window to be focussed again. Johannes confirmed that it was not possible to access the menu options in the parent form whilst there was a dialog box open, for both Microsoft Windows and the old wx version 2.4 drivers.

Bajusz Tamás (btami) noted that the latest released gnue-reports no longer worked with the last official release of GNUe Common, as it needs GRParser .py and GRSources from the current development version of GNUe Common. Reinhard Müller (reinhard) suggested should we do a release of gnue-reports now? would that help? Tamás said that it was really GNUe Common that was the problem. Reinhard said so we might want to look into releases for common and reports at least. However, he did not want to release forms in the middle of this stuff we are doing until it was more stable. He expected that the existing latest release of forms *should* work with the current development version of GNUe Common if they did a new release as of time of writing.

It was asked whether having an object ID field was necessary for databases being accessed by GNUe. Reinhard Müller (reinhard) said we currently depend on oids - because they are the only way of safely identifying a new record that has just been inserted if the primary key has been set by a db trigger. It was pointed out that, with Oracle at least, database-generated object IDs were not guranteed to remain the same over time. James Thompson (jamest) had not heard this, but in any case pointed out that postgresql 8.1 has depreciated the OID and no longer created them on tables unless specifically told too during the create table statemnet - this burns me quite a bit :) However, he had been under the impression that the data access code for GNUe only used the OID if a PK field wasn't defined for that table - if you defined what field or fields made up the primary key as part of the datasource definition, it would use these instead of requiring an object ID. He did this all the time with things like RMA numbers or order numbers - the user doesn't enter the PK value nor does the form - they save the new record and then the rma number assigned just pops up on their screen in the uneditable field :). This would normally be done by automatically re-querying the record after save - but I also seem to recall some dbsig drivers returning info from the execute of the insert. Reinhard confirmed this.

Reinhard Müller (reinhard) reported a problem with dropdowns (or other entries with a list of allowed values) - currently when a wrong value is entered, the complete entry is deleted and the field is set back to empty - and the cursor moves out of the entry - and no error message is displayed. I consider this a bug and would think the correct behaviour would be - display error message in status line, beep, leave the input as it was (so I can just correct my typo) and leave the focus in the entry. This was agreed.

Later, Reinhard reported an interesting problem - I've managed to block tabbing out of a control as long as the entered value is invalid - so when you hit tab or enter gnue-forms just beeps and shows an error message. However I seem to have no means to block moving the focus to another widget with the mouse - so you can still click out of a control even when the value is invalid - does anybody have any idea about this? Later, he thought he had found a solution that behaves fairly reasonable - but I guess it needs testing on different user interfaces.

The next day, Johannes Vetter did some testing of this fix on other user interfaces. He reported that using the wx 2.6 user interface driver in GNU/Linux seemed to work - clicking into another entry moves the UI-focus to that entry, but keeps GF-focus in the dropdown. entering new text goes still into the dropdown - the errormessage appears in the statusline. But the same form using the native Microsoft Windows 32 user interface driver was not working as intended - On win32, clicking into another entry moves both ui- and gf-focus into the new field, no message, no error. the value of the dropdown is the first one which was available depending on my input. However, using the wx 2.6 user interface driver in Microsoft Windows worked fine.

Further to , Johannes Vetter (johannesV) reported a response on the wx-mailing list regarding the grid problem - looks like some guys have implemented a grid-control (derived from wx.grid) which is capable of handling multiple rows per logical record - but it appears as the have troubles with selecting a row as well as moving around in a logical way. i've installed gnuecash yesterday to get a look at how they did it there ....

A few days later, Reinhard Müller (reinhard) noted that wow, zipgrid looks very nice already. Johannes said that there was still some tidying-up to do on the code, and it supports only default-entries as of time of writing. He posted some screenshots from GTK and Windows, noting that the best thing is it is done with just a few lines of gfd-code, giving the lines of code used to generate the sample grid.

Reinhard Müller (reinhard) asked anybody using gnue-reports on windows? He wanted to know whether you can print directly - or you have to generate a pdf which you then manually print? Later, Bajusz Tamás (btami) said that text-only reports could be printed directly to a printer, and if use xml formatter, can print to a gdi printer - text, html, escp,.., adding if you don't select a printer, it will pop up a selection dialog. He noted that all of this applied only to the current development version of reports, released doesn't works. He noted reports is far from a polished state as of time of writing.

Reinhard was approaching a project where we would need a number of reports - most of them probably being simple lists of records (maybe with master/detail, but nothing complicated). Tamás noted that the text-only version of reports did not support master/detail yet - there was no work on reports lately. Reinhard said we'll have to decide whether we use reports or do some manual python (maybe reportlab) based solution. Tamás felt it would be better to use/enhance gnue-reports - if everyone using custom report solution, it will be never finished - as i see, the engine itself is ready, the filters need more work.