Q re: Random Access Files, data-aware obj...

  • (13 Pages)
  • +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »

190 Replies - 13679 Views - Last Post: 23 June 2011 - 04:46 PM Rate Topic: -----

#31 chuckjessup  Icon User is offline

  • D.I.C Regular

Reputation: 33
  • View blog
  • Posts: 380
  • Joined: 26-October 09

Re: Q re: Random Access Files, data-aware obj...

Posted 02 March 2011 - 05:37 PM

View PostBobRodes, on 02 March 2011 - 11:09 AM, said:

Ok. Maybe it's time to model out the data class. What methods and properties should it have, do you think?


Mind you that the i am aiming for the vast majority of data handling to be dealt with by a dll file that i also am working on.

well it needs to open the database files for the requesting program, I know that this is a bit taxing on memory, but, I think it will be easier to work through the database files. I also am working towards putting more information in fewer files, so fewer files have to be opened.

It needs a search function,,, (the one i have been working on only pulls exact matches, i am trying to find a way to figure a wildcard for general searches... none so far have been successful. They either work with one item or none...)

It needs to have a function for each item: Move first, Next, Prev., Move last, Add, Edit/Update, and delete/remove records for fields.

It needs a function for sending information back to the specified application.

It would be nice if i could get some of the fields indexed, so that searching is quicker and easier... Just a nice thought...

It needs a way to detect when the files need to be closed so that some other instance can open the database.

Jesse Fender
Was This Post Helpful? 0
  • +
  • -

#32 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 02 March 2011 - 06:32 PM

Yes, I agree. We are designing the interface for your DLL file. So, why does the requesting program care if it opens the database files or not? Furthermore, does the requesting program care about moving around, or does it just want data? Why does the client care whether things are indexed?

In other words, most of the things you are talking about have zero to do with the interface. (Sorry! :))

Think about it this way. Your toaster is a client for the electrical interface, as exposed by the sockets in the wall. The toaster only cares about two things:
1. Stupid plug fits in stupid socket.
2. When plug goes in, electricity comes out.

That's an interface (oversimplified, I know, electricity has to be 60Hz, 110 volts, and so on, but you get the idea). The point is that the toaster couldn't care less how electricity is generated or how it makes it to the socket.

So. What does a consumer of your data (in other words, one of your applications) need to be able to get exactly, and when, and why?
Was This Post Helpful? 0
  • +
  • -

#33 chuckjessup  Icon User is offline

  • D.I.C Regular

Reputation: 33
  • View blog
  • Posts: 380
  • Joined: 26-October 09

Re: Q re: Random Access Files, data-aware obj...

Posted 02 March 2011 - 08:28 PM

View PostBobRodes, on 02 March 2011 - 05:32 PM, said:

Yes, I agree. We are designing the interface for your DLL file. So, why does the requesting program care if it opens the database files or not? Furthermore, does the requesting program care about moving around, or does it just want data? Why does the client care whether things are indexed?

In other words, most of the things you are talking about have zero to do with the interface. (Sorry! :))

Think about it this way. Your toaster is a client for the electrical interface, as exposed by the sockets in the wall. The toaster only cares about two things:
1. Stupid plug fits in stupid socket.
2. When plug goes in, electricity comes out.

That's an interface (oversimplified, I know, electricity has to be 60Hz, 110 volts, and so on, but you get the idea). The point is that the toaster couldn't care less how electricity is generated or how it makes it to the socket.

So. What does a consumer of your data (in other words, one of your applications) need to be able to get exactly, and when, and why?


OK. The data matching the data control (text boxes, combo boxes etc...) on the main form need to really get data from the database when the control selects an item from them. (This is done so that the data is accessible for the user to see the data from the file displayed in the form in reasonable order.)

To be able to recover records from a database file when the search command button is pressed, and displayed on/in the fields on the form or in a data grid layout. (This is so that a user can perform a simple look up for information from the database to a readable format on the UI... The other purpose for this is to do a record lookup for information stored by the user from the database to a user friendly set of controls, or grid.)

and when a command button is pressed to put information from the fields on a form into a specified database file. (the reason for this is to build or remove/delete records to/from the database...from the UI to the file.)

The above is as simple as i can explain how i read your question...

Jesse Fender
Was This Post Helpful? 0
  • +
  • -

#34 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 02 March 2011 - 10:02 PM

Ok. Let's not talk about anything having to do with the UI just yet. See, your database doesn't care whether you press a command button to get the data, or whether you do something else to get it. It cares about giving out the data when asked.

I get the feeling that you don't quite understand what methods and properties are yet. Do you, or shall I explain them further?
Was This Post Helpful? 0
  • +
  • -

#35 chuckjessup  Icon User is offline

  • D.I.C Regular

Reputation: 33
  • View blog
  • Posts: 380
  • Joined: 26-October 09

Re: Q re: Random Access Files, data-aware obj...

Posted 03 March 2011 - 03:08 PM

View PostBobRodes, on 02 March 2011 - 09:02 PM, said:

Ok. Let's not talk about anything having to do with the UI just yet. See, your database doesn't care whether you press a command button to get the data, or whether you do something else to get it. It cares about giving out the data when asked.

I get the feeling that you don't quite understand what methods and properties are yet. Do you, or shall I explain them further?


Well to be completely honest i dont really...

Jesse Fender
Was This Post Helpful? 0
  • +
  • -

#36 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 03 March 2011 - 07:27 PM

LOL Complete honesty is always best. I'm a little fluey, so I'm going to rest up a bit and think about what to say.
Was This Post Helpful? 0
  • +
  • -

#37 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 04 March 2011 - 12:07 PM

All right, feeling a bit better this morning. Ok. Objects are software entities that perform units of work. Each object performs its work for other objects, or via user interaction. An object that has some sort of user interface is called a control.

The value of using objects is that they hide the complexities of their implementation from their clients (whatever is using the object). As an example, let's say a command button, when pressed, is to fetch some data and display it in a text box. The button doesn't care how it gets the data, it just wants the data. What's more, the data object doesn't care how the command button will use the data, it just wants to get it and send it.

Objects "expose their functionality" through methods. Methods are stuff that an object does. Other objects call the object's methods. Let's use the same example of a command button needing to display data in a text box. So it asks the data object (the one you've written) for the data, using an agreed-upon METHOD of asking: for example "DataObject.HeyGimmeSomeData("SomeBodysIDNumber"). Now, the data object doesn't care what the command button is doing with the data, it just wants to hand it over in the most efficient way possible.

Objects also have attributes. Attributes are stuff that an object is. (We usually think of attributes as "properties" but there's a distinction that I will explain.) For example, a command button may be enabled or disabled, visible or invisible. Attributes are accessed and set via methods, too (although it doesn't seem that way), called "accessor methods". The term "property" actually refers to an attribute and all its accessor methods, so it's reasonable (and typical) to think of an object as having methods and properties. The reason I'm making this distinction now for you is because if you create your own class, and create properties for it, you will in fact need to create a variable to hold the attribute, as well as a "Property Get" and a "Property Let" procedure.

An interface is all the methods and properties of an object.

Classes are designs or "blueprints" for objects. In fact, the analogy of a blueprint is quite precise: A class is to an object as a blueprint is to a building. An object is a runtime "instance" of a class, and you can say a building is a realtime instance of a blueprint.

A component is all of the classes in a single library. A DLL is the best-known example of a component. The full name of a class would be ComponentName.ClassName, for example ADODB.Recordset. In VB, an ActiveX DLL has a name, and it has one or more Class Modules, each with a name. This is a component with classes in it.

So in designing your data serving class, what methods do you think you would want to have? Probably just a few...

Does this help?

This post has been edited by BobRodes: 04 March 2011 - 12:18 PM

Was This Post Helpful? 0
  • +
  • -

#38 chuckjessup  Icon User is offline

  • D.I.C Regular

Reputation: 33
  • View blog
  • Posts: 380
  • Joined: 26-October 09

Re: Q re: Random Access Files, data-aware obj...

Posted 05 March 2011 - 05:48 PM

Sorry about the time to get back with you... The reading gave me something to think about... I guess only a few methods would be needing to be exposed to the applications, namely:

one to get data from my program
one to get data from my dll/class

Then just use other classes to deal with the other parts... like searching, and charts and grids... i dont know but the two methods above are the ones that would be sbsolutly needed.

The other thought is that there be a input method(app->dll) and the return method being the same(dll->app) but that seems a little crazy...

What do you think?

Jesse Fender
Was This Post Helpful? 0
  • +
  • -

#39 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 06 March 2011 - 12:58 AM

No, doesn't seem crazy. The data class should be the sole interface between the database and the rest of the application.

You're doing fine. Now, let's talk a bit about cohesion and coupling. You might want to read up on these a bit yourself.

Cohesion means that a class handles pretty much one thing. An indicator that a class lacks cohesion is that it has excessive decision logic, meaning that it spends too much time figuring out which of a number of not very related things it has to do at any given moment. If it spends so much time doing that, maybe it ought to be broken up into more than one object.

Loose coupling is another thing to work for. Overly tight coupling is indicated by too much communication between objects. If they spend so much time communicating, maybe they ought to be one object.

So, keep going. You're very much on the right track now, having discovered that good interfaces are generally simple. Think about encapsulating units of related functionality, and exposing that functionality to the rest of your application through interfaces.

This post has been edited by BobRodes: 24 June 2011 - 01:14 PM

Was This Post Helpful? 0
  • +
  • -

#40 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 06 March 2011 - 01:04 AM

By the way. As for your input method, etc.
Public Function GimmeMyData(WhatDataIWant as StringMaybe) As SomeKindOfDataStructure
So yes, just one method. You pass some string like maybe an ID number, and you get back a record. Or maybe a bunch of records that fit a set of criteria that you pass. Or something like that.

Don't be afraid to be ruthless about trimming the fat from your thinking. :)

This post has been edited by BobRodes: 06 March 2011 - 01:05 AM

Was This Post Helpful? 0
  • +
  • -

#41 chuckjessup  Icon User is offline

  • D.I.C Regular

Reputation: 33
  • View blog
  • Posts: 380
  • Joined: 26-October 09

Re: Q re: Random Access Files, data-aware obj...

Posted 06 March 2011 - 02:21 AM

I have decided that the dll file will have multiple classes that have the in and out, and each program will have a class to handle the in and out functions to the application.

Sounds more complex than what it really is...

take for instance, the talk coordinating planner... since the application has the most to gain from this new data system... i will "diagram" the class layout in general terms...

Application - > DLL.Tcpclass
The tcpclass will get the data from the program, using the GET method
and calls the DLL.Search(args) with the data where:
the search will search the required data, and return to either: the tcpclass OR the TCP application directly.

The other option i have been milling through my head was the ability to have a class per application, again using TCP as the example:

Application -> DLL.TcpClass.something(args)
the application calls directly to the something class, such as the search function i have been trying to get to work...
Search will then send the information to the application using another function to send the data to the application to be displayed or otherwise handled.

Dont get me wrong i really havent got an idea about how to finish the code for the dll yet, i am working on it...

Jesse Fender
Was This Post Helpful? 0
  • +
  • -

#42 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 06 March 2011 - 01:04 PM

View Postchuckjessup, on 06 March 2011 - 09:21 AM, said:

I have decided that the dll file will have multiple classes that have the in and out, and each program will have a class to handle the in and out functions to the application. Sounds like a terrible idea. LOL

Sounds more complex than what it really is... Even to you, it would seem.

take for instance, the talk coordinating planner... since the application has the most to gain from this new data system... i will "diagram" the class layout in general terms...

Application - > DLL.Tcpclass
The tcpclass will get the data from the program, using the GET method
and calls the DLL.Search(args) with the data where:
the search will search the required data, and return to either: the tcpclass OR the TCP application directly. Let's leave this decision open for the present.

The other option i have been milling through my head was the ability to have a class per application, again using TCP as the example:Why? The point is about having only one bit of code that all the clients can use. Why do you need a different class for each application? Maybe you do, but you need to add complexity with reluctance, not relish.

Application -> DLL.TcpClass.something(args) This looks pretty good, but why can't it return the results of the search function as well? why do you need another class to do that? Simplify, simplify...
the application calls directly to the something class, such as the search function i have been trying to get to work...
Search will then send the information to the application using another function to send the data to the application to be displayed or otherwise handled. You didn't quite understand my example it would seem. Why do you need two functions when one will do?

Dont get me wrong i really havent got an idea about how to finish the code for the dll yet, i am working on it... I wouldn't start working on the code until I had my interfaces designed. Otherwise you'll have to go back and change it every time you change the interface. Avoid red herrings and wild goose chases...

Jesse Fender

Ok. You're on the right track, but need to avoid getting mired in details before you have your structure fully thought out. Suppose you simply list the methods of your Data class for now. Come up with real names, real arguments, real variable types. This is the core. Get this down, and the rest will follow more easily.

This post has been edited by BobRodes: 06 March 2011 - 01:08 PM

Was This Post Helpful? 0
  • +
  • -

#43 chuckjessup  Icon User is offline

  • D.I.C Regular

Reputation: 33
  • View blog
  • Posts: 380
  • Joined: 26-October 09

Re: Q re: Random Access Files, data-aware obj...

Posted 07 March 2011 - 05:36 PM

View PostBobRodes, on 06 March 2011 - 12:04 PM, said:

View Postchuckjessup, on 06 March 2011 - 09:21 AM, said:

I have decided that the dll file will have multiple classes that have the in and out, and each program will have a class to handle the in and out functions to the application. Sounds like a terrible idea. LOL

Sounds more complex than what it really is... Even to you, it would seem.

take for instance, the talk coordinating planner... since the application has the most to gain from this new data system... i will "diagram" the class layout in general terms...

Application - > DLL.Tcpclass
The tcpclass will get the data from the program, using the GET method
and calls the DLL.Search(args) with the data where:
the search will search the required data, and return to either: the tcpclass OR the TCP application directly. Let's leave this decision open for the present.

The other option i have been milling through my head was the ability to have a class per application, again using TCP as the example:Why? The point is about having only one bit of code that all the clients can use. Why do you need a different class for each application? Maybe you do, but you need to add complexity with reluctance, not relish.

Application -> DLL.TcpClass.something(args) This looks pretty good, but why can't it return the results of the search function as well? why do you need another class to do that? Simplify, simplify...
the application calls directly to the something class, such as the search function i have been trying to get to work...
Search will then send the information to the application using another function to send the data to the application to be displayed or otherwise handled. You didn't quite understand my example it would seem. Why do you need two functions when one will do?

Dont get me wrong i really havent got an idea about how to finish the code for the dll yet, i am working on it... I wouldn't start working on the code until I had my interfaces designed. Otherwise you'll have to go back and change it every time you change the interface. Avoid red herrings and wild goose chases...

Jesse Fender

Ok. You're on the right track, but need to avoid getting mired in details before you have your structure fully thought out. Suppose you simply list the methods of your Data class for now. Come up with real names, real arguments, real variable types. This is the core. Get this down, and the rest will follow more easily.


Ok i have been giving some thought into the subject. and the procedures that would be needed in the dll file... this list is bot final but sould be somewhat simple.

Class name =>FDFDb
The first proceedure...
StartConnection(DBFileName as string, LastRecFile as string)
SearchDB(SearchStr as string, SearchType as integer)
WriteDB(DBFileName as string, LastRecFile as string, DataToWrite(#) as string) '<--the (#) is a number for the data being sent the proc... more**'
ReadDB(DBFileName as string, LastRecFile as String, DataToRead(#)as string)' <-- same as the above** some having the optional tag added **'
RemoveItem(DBFileName as string, LastRecFile as string, DeleteRec as string)


I think that would basicly cover the items being dealt with directly by the dll... at least thats what i came up with so far.

Jesse Fender
Was This Post Helpful? 0
  • +
  • -

#44 BobRodes  Icon User is offline

  • Your Friendly Local Curmudgeon
  • member icon

Reputation: 574
  • View blog
  • Posts: 2,989
  • Joined: 19-May 09

Re: Q re: Random Access Files, data-aware obj...

Posted 07 March 2011 - 11:39 PM

View Postchuckjessup, on 08 March 2011 - 12:36 AM, said:

Ok i have been giving some thought into the subject. and the procedures that would be needed in the dll file... this list is bot final but sould be somewhat simple.

Class name =>FDFDb
The first proceedure...
StartConnection(DBFileName as string, LastRecFile as string)
SearchDB(SearchStr as string, SearchType as integer)
WriteDB(DBFileName as string, LastRecFile as string, DataToWrite(#) as string) '<--the (#) is a number for the data being sent the proc... more**'
ReadDB(DBFileName as string, LastRecFile as String, DataToRead(#)as string)' <-- same as the above** some having the optional tag added **'
RemoveItem(DBFileName as string, LastRecFile as string, DeleteRec as string)


I think that would basicly cover the items being dealt with directly by the dll... at least thats what i came up with so far.

Jesse Fender

Ok, now we're beginning to get down to it. Let's look at each of your methods. First, why is your client responsible for managing connections? Perhaps it would be better to optimize the connecting with the data class. This is a concept of coupling. Next, why do you separate out a search concept from a read concept? Mightn't they go together? Seems to me that search is nothing more than reading a subset of the total data.

Standard data operations are to get, add, alter, and delete data. Does your client need more than those? Does it need all of those?

Now that I've said that, think about your StartConnection method. Why is it anyone's business, so to speak, when the data class starts a connection? Aren't you kind of telling it how to do its job?

Keep at it. You're moving right along.
Was This Post Helpful? 0
  • +
  • -

#45 chuckjessup  Icon User is offline

  • D.I.C Regular

Reputation: 33
  • View blog
  • Posts: 380
  • Joined: 26-October 09

Re: Q re: Random Access Files, data-aware obj...

Posted 08 March 2011 - 03:00 AM

View PostBobRodes, on 07 March 2011 - 10:39 PM, said:

Ok, now we're beginning to get down to it. Let's look at each of your methods. First, why is your client responsible for managing connections? Perhaps it would be better to optimize the connecting with the data class. This is a concept of coupling. Next, why do you separate out a search concept from a read concept? Mightn't they go together? Seems to me that search is nothing more than reading a subset of the total data.

Standard data operations are to get, add, alter, and delete data. Does your client need more than those? Does it need all of those?

Now that I've said that, think about your StartConnection method. Why is it anyone's business, so to speak, when the data class starts a connection? Aren't you kind of telling it how to do its job?

Keep at it. You're moving right along.


Well since i am not using the ado connection, i am having to figure that i will be needing to code more of the "not so pretty" parts of the code, such as the connection to open a needed db file, or sets of files...

the getting data = read, add and possibly edit =write, delete =remove... since searching for items has proven to be more difficult than it would seem i have made it a separate procedure... as i saw fit at the time i was working on this.

And have added one, i found that during a test that the program was getting ahead of its self i added a "Waiting" procedure that simply is a bool that exits the sub if true, and pops a message box up, stating that you have to wait a sec... otherwise it is cool and moves on...

I don't know... it seems pretty straight forward in my head how every thing is laid out... but who knows...

Jesse Fender

P>S> Bob thanks for being patient with me, i know it probably isn't easy...
Was This Post Helpful? 0
  • +
  • -

  • (13 Pages)
  • +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »