Hi Max, >>> [X] I think it's finished, and I just don't dare to say ;-) > > ouch, now I remember again the last remaining issue. According to > [EMAIL PROTECTED], bracket matching does not work on Mac, no idea why. > > Would you have access to one and could debug there? Otherwise, I get > mine in 1 - 3 weeks and could debug it then, but then we might miss > feature freeze, which would be really unfortunate.
I don't have time at the moment for debugging this on the Mac, sorry (the more since debugging on the Mac is a cumbersome task. Well, to put it the other way round: I have only minimal experience with the tools on this platform.). Sounds like a task which we could postpone, IMO, provided the CWS'es QA rep agrees. Which brings me to: Our QA here in Hamburg is busy with a lot of other CWS' which are targeted for 3.1, too. But hey, nobody says a CWS'es QA rep needs to be a Sun-paid QA engineer, right? I suggest we ask - here and in [EMAIL PROTECTED] - for a volunteer who has a look at this CWS. What do you think? > > However, you should rebase your CWS to m35, since m34 saw some big > > changes in dbaccess. I am not sure they would conflict, but we should > > be sure > > Yup, will do right after Peking. Okay. Other than that: Did you have a chance to talk about the default colors with Bettina? I still think "light green on white" is ... eye-hurting :) I also spent some time reviewing your code changes. The following is a list of items I came across - nothing you're required to change, but I mention them for completeness (otherwise my review time would have been wasted :). - Any reason why m_pSourceViewConfig and m_pColorConfig are allocated dynamically? The instances could have been direct members. - overloading OSqlEdit::Notify is superfluous (in case it's just here because of a compiler warning - a "using" directive on the class declaration should do). - MultiLineEditSyntaxHighlight should be in an own file - crowding one file with unrelated classes doesn't really contribute to code lucidity. (Well ... that's the only item I would really *like* to see be changed :) - I would have preferred making larger chunks of the highlighter code a parametrization of the MultiLineEditSyntaxHighlight and SyntaxHighlighter classes, instead of hard-coding them. That is, IMO the keyword list, the token types, and everything else which is language specific (Basic or SQL), should have been hidden behind an abstract interface, which then is implemented once in basctl for Basic, and once in dbaccess for SQL. This would have been a much cleaner architecture. However, I see that the old code was in no way prepared for this, and changing this is a too big refactoring for now. Okay, enough for now. Please do the resync when you find the time (if you're really too busy, I can try to do myself, so we have chances of hitting the feature freeze, but I can't promise). Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
