Hi Marc, >> Well, the field formatting requires exactly that the value is displayed >> in the respective control/field, and then compared with the search term. >> The original intention was to allow searching for substrings in such >> fields, which is up to impossible when you don't apply the same >> formatting as the field has. So, leaving out the updates is not a good >> option. > > I do not understand completely. Isn't it possible to get the displayed > string from the view (aka control in this case)?
Ehm - yes, that's what we do. But for this they need to be updated ... I have the feeling we talk past each other here ... What we do with this setting is effectively the same as if the user would press the "next record" button (thus the complete UI update), and then compare the control content with the search term. Not doing the former would make the latter impossible. > >> However, it might be possible to solve this differently >> (finally, it's only the same formatting which is required to be used. >> This does not necessarily imply we must have the overhead of all those >> field updates.) > > Looking at it from my experiences this is most likely the case. Updating > the GUI is one of the most time consuming tasks generally. This depends ... usually we say that UI is cheap, at least when we talk about dialogs and such. However, forms have *a lot* of abstraction layers involved, which might make this particular UI expensive. (sometimes I think the Solaris people where right - I once read a document from some Solaris core developers saying "layers are for cakes, not for software" :) >> For other bottlenecks, we'd need to do a detailed profiling, perhaps we >> would detect some hot spots. > > This leads back to the remark from my last mail. Sorry, that slipped me. > How much effort would > that be for someone never having compiled the office and necessary > environment (solver?) herself? Money- or time-wise? :) The most comprehensive profiling tools (at least the once I know, which means on Windows) cost an awful lot of money. There's a mechanism in OOo which allows putting tracing information into the source code, which can later be evaluated by some perl scripts. This is a relatively simple way (once you got your OOo build environment running), which is quite good for quite some cases. It however requires you know where to start looking: You put some marks around the most expensive pieces of code, at some high level. Then you use some "divide an conquer" tactics: Divide the expensive piece, look for the most expensive sub piece, step down into the methods called there ... Requires much of recompiling and retesting, but nonetheless it can be very successful if you have one or a few hot spot(s) which you need to find. > I don't know if it would help potential developers if there were some > UML diagrams or something making the internals of base more clear. It most probably would, alas - we don't have them, and I don't see we will be able to create them on the short run ... 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]
