Are you saying that RB Ubound does an iterating count of the number of
elements each time ??
I would have thought that each RB array has an internal count "property"
that only gets modified as elements are added or removed, and this property
is what gets queried each time Ubound is called. I might be wrong but that
would seem the most efficient thing to do - at the cost of a single integer.
On 17/5/07 15:30, "James Sentman" <james at sentman dot com> wrote:
>
> The problem is that you're evaluating the ubound everytime you go
> around the loop. The higher the ubound value the more times you'll
> have to evaluate it and the slower your loop will run.
Regards,
Dan
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
From Thu 17 May 2007 08:48:38 -0600
Return-Path: <realbasic-nug-bounces at lists dot realsoftware dot com>
X-Original-To: listarchive at realsoftware dot com
Delivered-To: listarchive at realsoftware dot com
Received: by xmail.realsoftware.com (Postfix, from userid 1037)
id E5616266E20E; Thu, 17 May 2007 07:48:51 -0700 (PDT)
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
www.realsoftware.com
X-Spam-Level:
X-Spam-Status: No, score=-3.0 required=4.5 tests=ALL_TRUSTED,AWL,BAYES_00,
NO_REAL_NAME autolearn=ham version=3.1.1
Received: from lists.realsoftware.com (m.realsoftware.com [66.116.103.65])
by xmail.realsoftware.com (Postfix) with ESMTP id 42D16266E202;
Thu, 17 May 2007 07:48:46 -0700 (PDT)
Received: from real-software-mini.local (localhost [127.0.0.1])
by lists.realsoftware.com (Postfix) with ESMTP id 6FAEE2D8F60;
Thu, 17 May 2007 09:48:39 -0500 (CDT)
X-Original-To: realbasic-nug at lists dot realsoftware dot com
Delivered-To: realbasic-nug at lists dot realsoftware dot com
Received: from mail.verex.com (mail.verex.com [66.116.103.197])
by lists.realsoftware.com (Postfix) with ESMTP id 119942D8F55
for <realbasic-nug at lists dot realsoftware dot com>;
Thu, 17 May 2007 09:48:36 -0500 (CDT)
Received: from [66.116.103.197] (localhost [127.0.0.1])
by mail.verex.com (Postfix) with SMTP id 4B5CD7517D2
for <realbasic-nug at lists dot realsoftware dot com>;
Thu, 17 May 2007 08:48:38 -0600 (MDT)
Date: Thu, 17 May 2007 08:48:38 -0600
Subject: Re: Grid Control: desired feature set
From: joe at strout dot net
To: realbasic-nug at lists dot realsoftware dot com
In-Reply-To: <33cbfa100705162345t127e2c43q69fa790590f3b370 at mail dot gmail
dot com>
X-Mailer: VerEx Email Gateway
Message-Id: <20070517144838 dot 4B5CD7517D2 at mail dot verex dot com>
X-BeenThere: realbasic-nug at lists dot realsoftware dot com
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: realbasic-nug-bounces at lists dot realsoftware dot com
Errors-To: realbasic-nug-bounces at lists dot realsoftware dot com
On May 17, 2007, at 06:45 UTC, Lars Jensen wrote:
> > > - Variable-height row data implies that the grid can repaginate
> > > itself on demand, such as during a resize.
> >
> > Can you explain what you mean by "repaginate"?
>
> I mean the case where you want each row to wrap its contents to the
> width of the column, and adjust the row height as a result. I call it
> "repagination" when the column width changes and each row has to
> recalculate its height.
Oi. Interesting. But I guess, if there's a ColumnWidthChanged event
that gets invoked whenever the column width changes, then you could use
this to adjust the row heights. (This would trigger a RowHeightChanged
event, but I think you could ignore that.)
> Oh, and here's another case, somewhat related to the one above: one
> should be able to choose whether this control scrolls by row or by
> pixel. By row is most common of course, but by pixel has its uses too.
I think it should always be by pixel. Is there a good argument for
sometimes scrolling by entire rows? Any well-known examples?
> This is fun! Here's another one: I would like to be able to draw into
> neighboring cells on occasion.
I believe this is the "cell merging" feature that was one of the first
asked for. You just say, "merge cell C5 with C6" and now you get a
single CellTextPaint event with a context that spans both areas.
> And how about an easy way to draw vertical headers for those narrow
> columns? (Yeah, I know, draw my own...)
Yeah, if it's just an event, then you can draw whatever you want.
> One more: Column headers that span columns.
I'm not sure about this, but I'm thinking that column (and row) headers
should just be cells with specially-drawn content in them, and some
special handling for mouse interaction. (Plus of course the ability to
"freeze" certain rows/columns so they don't scroll.) So, if we already
have cell merging, then we automatically have header merging (i.e.
span) too.
> But of course it's not that simple if this
> control supports dragging columns to re-order them, because at that
> point we'll want to support dragging _groups_ of columns by the
> spanning header!
I'm really not sanguine about drag-reordering of columns or rows.
Column/row resizing, sure. But reordering sounds hard, and I strain to
think of a good use for it (if you're not actually trying to duplicate
Excel!).
Best,
- Joe
--
Joe Strout -- joe at strout dot net
Strout Custom Solutions
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|