Breaking down the text in a multi-line text box... 2

[rickyoswaldiow]

Good evening all. Today I am trying to store the text typed into a text box into a database. Very simple you may say, but here's the catch; The text box is multi-lined and there is a seperate record for each line in the database. For example, the user will enter his address as follows
House Number
Street Name
City
State

But in the database there are seperate fields for each line; Address1, Address2...

Would it be easier to simply go back and change the form design to accomodate 5 seperate text boxes? There are a *lot* of references to the way I have it set up already, currently it reads from the database using this method:

with rsAddress
   Me.txtAddress = !Address1
   Me.txtAddress = me.txtAddress & vbCrLf & !Address2
   Me.txtAddress = me.txtAddress & vbCrLf & !Address3

end with

I'm guessing there is a way to read through a string and check for the vbCrLf or similar? Any help would be greatly appreciated!

 

[Nimroduk]

I'm guessing that the problem you're having is that there are (say) 5 lines of address in the DB but the user edits that down to 2 lines in the textbox. In this case only the first 2 lines are updated, the remaining 3 do not get emptied ?

This is because all of the loops are based on just storing the data in the textbox. You'll need to get your code to check to see if the number of lines is less than the number of records, if it is less then you'll need another loop that sets the remaining records to null/nullstring.

 

[Error7]

It may have been better to use multiple single line text boxes in an array, particularly for name and address data.

Using individual text boxes you can control the data that's entered: Street Numbers, Post / Zip Codes, Telephone Numbers etc.

[gray]Experience is something you don't get until just after you need it.[/gray]

 

[rickyoswaldiow]

It may have been better to use multiple single line text boxes in an array

Quite right, that is how the original system works

I'm guessing that the problem you're having is that there are (say) 5 lines of address in the DB

Spot on


The system has been built gradually over the years using Rapid Application Development. There are no comments in the code and a lot of quick fixes and work arounds. My task was to fix this and recently I have decided to write the whole system from scratch. At the moment I am producing documentation and planning for it - I will eventually be back to pester people with more questions but I am planning to build it in VB .net... Thanks very much for all the help you have given me over the last few weeks, I'll be seeing you soon(ish)

 

[strongm]

Just a quick aside: use of RAD does not preclude the use of comments, nor does it advocate the use of quick fixes and workarounds

 

[rickyoswaldiow]

Indeed... I used RAD a lot at college and half of my application would be comments. On a system of this size and scope however, it does not lend itself to RAD.

 

[BobRodes]

<At the moment I am producing documentation and planning for it
Keep in mind then that one of the best ways to produce documentation and planning that has anything much to do with the eventual result is to create prototypes (using your favorite RAD system) and present them to the stakeholders as proof of concept artifacts.

<On a system of this size and scope however, it does not lend itself to RAD.
It's almost like saying that English, being a "rhyme poor" language, doesn't lend itself to writing poetry! I've seen RAD type development methodologies on very large projects, and they have proven themselves to be not only more stable but also requiring fewer spec changes than some of the applications developed using more traditional (so-called "waterfall") methods. The point is not that RAD is therefore superior to more traditional methods, rather it is that the applications that run well were well managed during development, no matter what the methodology used. So I would suggest that if what you have isn't working, it probably isn't the methodology that is broken, rather it's the application of it in the enterprise you're in.

Applications like the one you describe generally have an antipattern like this:
1. Customers are the people who understand the needs that the application addresses. A group of customers regularly sit around a table and work out unilaterally the changes that they feel are appropriate for the application. These changes they communicate to the business advocates.
2. Business people are the people responsible for meeting the needs of the customers. As such, they have control of the change process, because it's their job to keep the customers happy.
3. Developers are the people that meet the needs of the business people, and so they create whatever changes the business people ask for.

The result is an application that doesn't work and is over budget. The refactoring is to educate the customers as to the risks involved with change, so as to balance the need for change with the risk entailed. That refactoring can often be a very difficult process, as it will in general be politically unpopular. It's much more convenient to blame the implementer of the antiprocess and find a knight in shining armor to slay the dragon created by his predecessor and then properly implement the plan (which is really just the "plan du jour", of course), than it is to admit that everyone who counts has been investing millions of shekels into going about things all wrong.

Now, I invite you to consider whether a change in methodology will realize whatever goals you have in place when you elect to write the application from scratch. Also I would caution you that whoever wrote this application was trying to keep people happy. If you try to keep people happy, you're going to write one just like it, only using a different development methodology, and then you will be the next person whose photo is superimposed on the dart board in the break room.

Here's a short article about some of the ongoing debate on development methodologies:

http://www.regdeveloper.co.uk/2006/02/23/waterfall_method/

Bob

 

[rickyoswaldiow]

rather it is that the applications that run well were well managed during development

That is exactly why it does not lend itself to RAD. Things are done without any documentation or notes - the system is a mess.

I invite you to consider whether a change in methodology will realize whatever goals you have in place when you elect to write the application from scratch.

Thankyou for the warning. What I am doing is taking one part of a much larger system that has been built in access/vba and migrating it to VB6 as a standalone application. I am not changing the GUI or the functionality - I am simply re-moulding the layout of the code, it is very messy from 6 years of quick fixes and adding new features.

Thanks for the link too, interesting read

 

[BobRodes]

<That is exactly why it does not lend itself to RAD. Things are done without any documentation or notes

Hmm...are you saying that RAD as a standard doesn't require sufficient documentation to be a valid development technique for large scale applications, or are you saying that RAD is not the best development model for applications that are not well managed?

<I am not changing the GUI or the functionality - I am simply re-moulding the layout of the code
Ahh, well that's a bit of a horse of a different color. I got the idea that you were going to redo the entire thing.

 

[rickyoswaldiow]

I think I am saying "I wish there was documentation and notes with this project..."

 

[BobRodes]

I see. Well, so do I.