Comments on: On-the-fly data entry form

By: Primo

Primo — Thu, 26 Jun 2008 09:30:00 +0000

Thanks. I saw that in one of your earlier posts, but I can get away with using the events that are available. Actually I don’t really need to do it at all, the form’s working fine without those boxes updating, and if I really needed them to update I could just go with building the form at design time. But it’s going to make the form look better and I’m with Mike above: “It’s more interesting…”

By: jkpieterse

jkpieterse — Wed, 25 Jun 2008 15:29:00 +0000

You need a class indeed. Note that a class will unfortunately not offer you all events you are used to having.

By: Primo

Primo — Wed, 25 Jun 2008 10:51:00 +0000

I’ve been trying to do something like this, but I’ve come up against a problem – I can’t set events on the controls that have been created on the fly. [I want a textbox to update when the value in another textbox is changed]. I’m thinking that I might be able to use a class to do this, but am I missing something simpler and more obvious?

By: jkpieterse

jkpieterse — Tue, 24 Jun 2008 17:20:00 +0000

Hi Mike,

"Also, it's more interesting to make one form smart than to make ten dumb forms!"

Ain't that true!!!

By: Mike Woodhouse

Mike Woodhouse — Tue, 24 Jun 2008 13:59:00 +0000

I think that once you have more than, say, two such tables, you’re well-advised to go for the single dynamic userform. (Actually, I’d seriously consider it at two).

Suppose you need to make some look-and-feel change, for example.

It keeps the whole thing DRY (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) which is generally a Good Thing.

Also, it’s more interesting to make one form smart than to make ten dumb forms!

By: aivars

aivars — Sat, 21 Jun 2008 09:12:00 +0000

use sqlite. Nobody will notice you are using a database. It rocks!

By: Matthew Pfluger

Matthew Pfluger — Fri, 20 Jun 2008 14:36:00 +0000

Jan Karel,

I, too, have been finding very specific reasons for staying with Excel. Particularly, the manager's fear of the unknown. Despite the ability to collect, store, analyze, and report data within a single, multi-user application, my coworkers do not see the benefit of a database in many applications. Frustrating at times... But, I won't get the thread too far off its original topic.

I might have used a multi-page control, but I like the flexibility of table-driven code. If you can handle the relational data accurately, I like the strategy.

By: Hans Schraven

Hans Schraven — Fri, 20 Jun 2008 10:45:00 +0000

I don't see any advantage in creating forms 'on the fly'. Or am I missing something ?
Felipe's suggestion makes sense to me, especially when the 'Style'-property has been set to 2-fmtabstylenone. The pages appear to the user as different userforms although they are not.
Depending on the sheet that has to be filled the corresponding page (tab) will be activated.
The way the data is written into the worksheet can be controlled in accordance to the active page of the multipage control.

By: jkpieterse

jkpieterse — Thu, 19 Jun 2008 18:53:00 +0000

I agree Access is by far better for relational databases. And in fact, the backend is a database. But there are specific reasons to stick with Excel for now.
I've been developing a lot in Access lately.

By: Doug Glancy

Doug Glancy — Thu, 19 Jun 2008 16:56:00 +0000

Matthew, a 2nd to your recommendation. I’m just discovering the joys of Access (just split my first database). The Ken Getz, et. al. Desktop Developer’s Handbook has been very helpful.