Am Mittwoch, den 04.07.2007, 09:11 +0200 schrieb Frank Schönheit - Sun Microsystems Germany: > Hi Marc,
Tach auch, > > 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. Now I see. Thinking about it this way it is getting clearer - setting the actual record position must be the first step. Without there's no visible field to ask for it's display string and there are only ca. 20-30 records in the actual view, okay. > > 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. What windows? You should be working, not looking outside ... ;) I was thinking about using gprof and cgprof or similar. But I fear this will make the office a multi-gigabyte-nineheaded-monster if compiled with "-pg". A small test app I've used lately has grown about factor 2-2.5 in size (dunno how much this would be loaded into memory). This strategy would have to be limited to some files only, but fiddling the build process of OO.o is not for the fainthearted. > 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. So the question is if it's worth the efford. But if gui updates are unavoidable this is not so promising. > > 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 ... I was hoping for some "internal" materials at sun that could be quickly overhauled to be published. Not only structure diagrams but some programming guidelines (e.g. I somewhere found some remarks on string formatting and using the different classes available) or whatever could be helpful to attract developers and make it easier getting the hands dirty. Marc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
