On 3/30/11 5:02 PM, Paul McNett wrote: > > I'd iterate the objects in z-order, drawing each based on their evaluated > expressions. In the case of an x or y not evaluating, I'd find the first > horizontal > or vertical position that doesn't cover up a previously-drawn object. > > Actually, now I've typed that I think it is too simplistic. Maybe following > what you > hinted at and offering these properties would help: > > DefaultX > DefaultY > DefaultWidth > DefaultHeight > DefaultExpr > > At design-time, if the appdev sets x to an expression that evaluates without > error, > DefaultX also gets set to that same literal, otherwise DefaultX keeps its > prior > value. If the appdev explicitly sets DefaultX though, it'll never be > overridden > automatically. > > So at design-time or run-time, if any of the properties don't evaluate, the > Default* > property will be used. > > I actually like this, and could get behind implementing it for all > properties, not > just the ones listed above, since all report properties are evaluated at > runtime. I think that design is the best. It allows the developer to see a better representation in the designer. +1 from me and I'll help you implement it. Is there a simple way to auto-generate all of the property definitions at run-time for the table so if we ever want to add new properties they will automatically have defaults included?
Also, just noticed the Image tag doesn't handle the error that is raised by the dImage object in the designer window if the supplied expression is a string... Regards, Nate _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[email protected]
