Board index » delphi » Attaching functions to objects...

Attaching functions to objects...

Hi there,

    I have a Business Object which maps onto a table row in a database.
Within each object I have an enumerated type that represents all the fields
within it, and this is used to create a constant mapping store, that maps
fields, types, sizes etc.  It also has the default information to drive
whether or not that field will appear in the generic Search grid I have,
plus its width and position.   This constant map is loaded at startup for
each Business Object into dynamic storage, so on Search of an object I
collect that from the Business Object I am searching on.

On the Search grid you can adjust these fields, make them visible or not,
resize, position etc.  The BusinessObjects are loaded into
BusinessObjectLists and for display purposes only each row is loaded into a
string list and the grids are mapped onto the columns.

By changing my model to do this generically I have come across some
limitations, the first is probably fairly simple to solve, and that it some
fields are currency, or floats by origin albeit as I said stored as a string
for display, but I want these fields to be Right Justified in the grid,
which is easy if I know that is what is required for a specific field, but I
am struggling to work out how or where to store some indiciator against that
field to force this kind of treatment for display.

The second problem is similar, but slightly more complex as all my time
fields are stored as seconds in the database, i.e. seconds from midnight,
and before I was mapping directly onto the data type of that field within
the Business Object, so I was able to call a function to convert it for
display, but now it is just in a string list based on the enumerated type of
that biz obj, so I need to be able to map that function against those fields
in my Dynamic storage of my mapping information, so that when it sees from
the dynamic mapping info that this field needs to have x done to it.

Sorry this took a little explaning, but I felt the background was important
to see a slightly bigger picture, and therefore a possible solution, I
suspect the first problem will solve the second.

Many thanks in advance
Colin B

 

Re:Attaching functions to objects...


I'm not sure it's possible to store a method in a file, but the classical
solution is to use a table of functions pointers. Then you just store an
index in you configuration file, and call the related function using
something like func_table[index](func_params);

Note that this index principle is used in DLLs, so using a DLL with all
required functions inside would avoid a specific table in your application.

Denis

Re:Attaching functions to objects...


Denis,

    I see what you're getting at, yes I'll have a play around with,

many thanks
Colin B

Quote
"Denis Jeanroy" <nospam@work> wrote in message

news:3c7df7b1$0$201$4d4eb98e@read.news.fr.uu.net...
Quote
> I'm not sure it's possible to store a method in a file, but the classical
> solution is to use a table of functions pointers. Then you just store an
> index in you configuration file, and call the related function using
> something like func_table[index](func_params);

> Note that this index principle is used in DLLs, so using a DLL with all
> required functions inside would avoid a specific table in your
application.

> Denis

Re:Attaching functions to objects...


Denis,

    I tend to learn by example, is there a place where I can find an example
of this DLL index principle in use, I can do a TDump on any DLL, I guess but
I assume from your reply that the parameters can vary from function to
function, and may not be function even, though in my case that wouldn't be
necessary..

Thanks again
Colin B

Quote
"Denis Jeanroy" <nospam@work> wrote in message

news:3c7df7b1$0$201$4d4eb98e@read.news.fr.uu.net...
Quote
> I'm not sure it's possible to store a method in a file, but the classical
> solution is to use a table of functions pointers. Then you just store an
> index in you configuration file, and call the related function using
> something like func_table[index](func_params);

> Note that this index principle is used in DLLs, so using a DLL with all
> required functions inside would avoid a specific table in your
application.

> Denis

Re:Attaching functions to objects...


Quote
"Colin Basterfield" <area...@onetel.net.uk> wrote in message

news:3c7df09e@212.67.96.135...

Quote
>     I have a Business Object which maps onto a table row in a database.
> Within each object I have an enumerated type that represents all the
fields
> within it, and this is used to create a constant mapping store, that maps
> fields, types, sizes etc.  It also has the default information to drive
> whether or not that field will appear in the generic Search grid I have,
> plus its width and position.   This constant map is loaded at startup for
> each Business Object into dynamic storage, so on Search of an object I
> collect that from the Business Object I am searching on.
> By changing my model to do this generically I have come across some
> limitations, the first is probably fairly simple to solve, and that it
some
> fields are currency, or floats by origin albeit as I said stored as a
string
> for display, but I want these fields to be Right Justified in the grid,
> which is easy if I know that is what is required for a specific field, but
I
> am struggling to work out how or where to store some indiciator against
that
> field to force this kind of treatment for display.

If instances of the business object encapsulate the information, have you
considered using Delphi's object streaming to store and retrieve instances
of these objects?

Re:Attaching functions to objects...


Hi Bruce,

This will sound lame, but what's object streaming?

Thanks for your help
Cheers
Colin

Quote
"Bruce Roberts" <b...@bounceitattcanada.xnet> wrote in message

news:Zjuf8.1334$a04.7980@tor-nn1.netcom.ca...
Quote

> "Colin Basterfield" <area...@onetel.net.uk> wrote in message
> news:3c7df09e@212.67.96.135...

> >     I have a Business Object which maps onto a table row in a database.
> > Within each object I have an enumerated type that represents all the
> fields
> > within it, and this is used to create a constant mapping store, that
maps
> > fields, types, sizes etc.  It also has the default information to drive
> > whether or not that field will appear in the generic Search grid I have,
> > plus its width and position.   This constant map is loaded at startup
for
> > each Business Object into dynamic storage, so on Search of an object I
> > collect that from the Business Object I am searching on.

> > By changing my model to do this generically I have come across some
> > limitations, the first is probably fairly simple to solve, and that it
> some
> > fields are currency, or floats by origin albeit as I said stored as a
> string
> > for display, but I want these fields to be Right Justified in the grid,
> > which is easy if I know that is what is required for a specific field,
but
> I
> > am struggling to work out how or where to store some indiciator against
> that
> > field to force this kind of treatment for display.

> If instances of the business object encapsulate the information, have you
> considered using Delphi's object streaming to store and retrieve instances
> of these objects?

Re:Attaching functions to objects...


you can find everything you need about DLLs in Dephi's help.
And delphi has a DLL wizard to help you building libraries.

about streaming: I think that a TStream or TFileString can be used to store
objects, but i really don't know if methods (= code, along with a pointer to
the method) will be stored and then restored at the same address. An address
function is supposed to vary with linking and not to be at the place in
memory everytime the program is executed.

Denis

Re:Attaching functions to objects...


Quote
Colin Basterfield wrote in message <3c7df...@212.67.96.135>...
>                    ...The BusinessObjects are loaded into
>BusinessObjectLists and for display purposes only each row is loaded into
a
>string list and the grids are mapped onto the columns.

This is the reason that TStrings is abstract. A memo has a
Lines property which conforms to the TStrings interface (it
has a value of TStrings class), but there is no TStringList
object beneath this. The memo has text contents, and when
you use the methods and properties of the memo's Lines, the
values are determined dynamically. The object used is not a
storage object but more of a dispatcher object.

I'm sure this concept translates to your list of business objects.

Groetjes,
Maarten Wiltink

Re:Attaching functions to objects...


Quote
"Colin Basterfield" <area...@onetel.net.uk> wrote in message
> This will sound lame, but what's object streaming?

The most obvious example is the Delphi IDE and the forms it displays. Each
form that you create is "streamed" to a .dfm file. That is, the objects on
the form are written to a .dfm file. When you re-open a form unit the .dfm
file is streamed in, creating the form that is displayed. You can fairly
easily write code that can save and load tPersistent (and its descendants)
to/from any stream, be it a file, blob field, etc. All published properties
are saved, including any event linkages.

Re:Attaching functions to objects...


Bruce,

    Yes I did that when I wrote some property editors for a component on on
previous contract, but what struck me about the responses I got to my
questions is how the threads weave their way in ways one couldn't have
anticipated, and that is why these newsgroups are so important, and so
usuful, especially when developers often work from home, often alone also,
and you are so isolated.

Thanks very much for your help.
Colin B

Quote
"Bruce Roberts" <b...@bounceitattcanada.xnet> wrote in message

news:rXDf8.1416$a04.8605@tor-nn1.netcom.ca...
Quote

> "Colin Basterfield" <area...@onetel.net.uk> wrote in message

> > This will sound lame, but what's object streaming?

> The most obvious example is the Delphi IDE and the forms it displays. Each
> form that you create is "streamed" to a .dfm file. That is, the objects on
> the form are written to a .dfm file. When you re-open a form unit the .dfm
> file is streamed in, creating the form that is displayed. You can fairly
> easily write code that can save and load tPersistent (and its descendants)
> to/from any stream, be it a file, blob field, etc. All published
properties
> are saved, including any event linkages.

Re:Attaching functions to objects...


Denis,

    Yes after I wrote that message I went into a DLL frenzy, and created one
which has my display functions, and I think have got some really great ideas
from everyone on here who took time out to give their views...

Thanks
Colin

Quote
"Denis Jeanroy" <nospam@home> wrote in message

news:3c7e8fe7$0$197$4d4eb98e@read.news.fr.uu.net...
Quote
> you can find everything you need about DLLs in Dephi's help.
> And delphi has a DLL wizard to help you building libraries.

> about streaming: I think that a TStream or TFileString can be used to
store
> objects, but i really don't know if methods (= code, along with a pointer
to
> the method) will be stored and then restored at the same address. An
address
> function is supposed to vary with linking and not to be at the place in
> memory everytime the program is executed.

> Denis

Other Threads