Hello All,

I don’t understand why this is happening.  

I have a form that creates another form that has a data module as in:

    Form1	
        Form2 with dmModule.Create(Form2)

The data module has a data source that is linked to a data aware combo box on Form2.  Everything works!

Now, if the first form has the same data module as in:

    Form1	with dmModule.Create(Form1)
        Form2 with dmModule.Create(Form2)

The data aware combo box on Form2 no longer works.  If I reassign the list source of the combo box on Form2 to the data source in the data module, it works:

    cmbobxName.ListSource:=dmModule.dsDataSource;  //This makes it work

Any ideas why the combo box needs its list source redefined?  What am I missing?

Thanks for your help,

Dave

Edited by: David Cox on Sep 17, 2014 3:43 PM

> {quote:title=Eduardo Elias wrote:}{quote}
> 
> Centralization is not the probleme, I think, the problem is put the responsabilities 
> on the right places. It is design. 

Good discussion. I think it best to use the approach that provides the most features and the best ux. Delphi provides a framework. Of course we could always create a different one. But if it can be done with what you already have go for it!

My validation rules are spread over the layers :) 

For example, as I am using ORM, the Entities are classes, not just records. 
So the knowledge of UpperCase like you asked is up to the class to understand. 


It can be hardcoded, then you need to recompile and create a new version 
if you need to change.

Or you can store it on a config that the classes load that config and take 
the right behavior. That config could be in a SQL server (via ORM either)

I am not a purist. However I am not in the middle. I dont know where is the 
middle.

Right now I am using MVP, but besides I am pushing it on this talk, I dont 
necessarily consider it the only option. You need to separate responsabilities 
on your code, if you do that correctly you will fall on one of the patters. 
So if you learn them helps. But I dont stick with them. 

For example, I start using Observer partern and got bored with it... now 
I use in very few places.

If I need to validate a complex form it will have levels of validation. Presenter 
validate obvious things (that usually would be the view), the entity when 
trying to be saved will validate itself and then the model will validate 
the entity againt the business rules. That all on the client side. When using 
server, I use the XData from TMS, where it adds a ORM layer behind it, so 
that layer go more deep. 

The SQL server only does the very basic Constraint rules validations. Nothing 
else, so I can easily switch SQL servers.

When something goes wrong there is a error raising mechanism and go all the 
way back to the presenter, where it brings the proper message to the user.

It is harder to write this way, thinking in one objective view/form. But 
the result is solid and changes do not break things so easily.

My overall circle of development/testing/deployment is very different now. 
Let say that 80% of the time is expent on Dev.

About the browser thing, in this case the user already understands that with 
no connection, no work. So this is not an impact, at least in this case.

Centralization is not the probleme, I think, the problem is put the responsabilities 
on the right places. It is design. 

My 2 cents.


>> {quote:title=Eduardo Elias wrote:}{quote}
>> 
>> Based on your comments you seems to be old Delphi RAD guy somewhere
>> Delphi 2 or 3  ;)
>> 
> Yes I started with Delphi v1 doing RAD stuff. Then I went through all
> the "code it up" undulations that most go through. Now as I look back
> on my older stuff. Some of it running 10+ years without changes. I
> wonder if all those efforts to be purist were really worth anything
> more than learning what else is available.
> 
>> Depends of what you call smaller systems. Many programs? Classes?
>> What?
>> 
> Well most everything. One big program or one big unit or one big class
> isn't good. Look at mobile apps. If people would have created a
> dedicated data module for each form or master form. Something many
> here suggested against, myself included, at one time or another. The
> dev could easily pull out the dm and the related forms then with a
> little tweaking compile a mobile app. Now that's an awesome way to
> move a system to mobile! But with not wanting to use duplicate data
> set components and trying to reuse da
> 
> ta modules across forms you have to more or less create a new mobile
> app from scratch. Or you have to untangle the connections. In other
> words the redundancy of the beginner is now a benefit.
> 
>> Are you sure you using Delphi all these years?
>> 
> Yes I'm fairly certain of it. Unless the world I live in doesn't
> actually exist. :-)
> 
>> You are talking like Client/Server stuff.
>> 
> I know the MVC approach. But I'm saying. Don't get stuck thinking
> about being a purist of one or another approaches for this discussion.
> Think first the user then worry about the implementation.
> 
>> Central location is not a server. Try reading some MVP, MVVM or MVC
>> stuff and you will understand the differences on how to separete the
>> layers
>> 
> I understand those. I thought you were meaning one server.
> 
>> Right now I am sucessfully using VCL FMX and UniGui, 3 different
>> frameworks, with the same software. I need only to rewrite the View
>> (the form). There is no code at all on the view.
>> 
> So what kind of logic do you include with a mobile app? For example...
> If the mobile app user is entering some data and the business rules
> require all first letters of words to be capitalized. Must the mobile
> app post the data to the server *before* it will check the business
> rule of first letter capitalized?
> 
>> User experience has nothing to do with the choosen framework. User
>> experience needs to be best always.
>> 
> I think user experience is impacted by the framework sometimes. I
> agree that the ux should always be best. Like for example when using a
> browser app and I can't do any work because the internet went down.
> That's not the best and the framework causes that.
> 
>> There is nothing related to centralized server here. If you learn MVP
>> for example you will see that.
>> 
> I understand MVP. You're just proposing that it's the best. I'm not
> making that assumption.
> 
>> I have a ORM layer to deal with SQL.
>> 
> I like ORMs.
> 
>> the Model contacts the server for data.
>> 
> But, again, where is the ux logic? Do the screens the user interacts
> with need to post to a remote layer for all logic or is there logic on
> the mobile device?
> 
>> When you get close the user things are easier.
>> 
> But are they as robust? Can the user see a violation of the rules
> before they've finished a large screen and then posted their work?
> 
>> The logic is spread. Each place with the rules that are appropriate.
>> but not in the form
>> 
> So when are the rules applied? Can the user still run the app without
> being connected and sync when the connection is back?
> 
>> I am serving my own interstest that is giving the best to the user
>> with the better from programming.
>> 
> But if the user must be connected to find out if what they are doing
> follows the business rules then I would contend you're serving the
> programmer and not the user. The user should not have to be connected
> 100% of the time to work.
> 
>> I dont understand what is your problem, seems that you learned to
>> count 1, 2, 3 and anything different of that causes fear.
>> 
> I would contend here that you only want to accept MVP.
> 
>> Here is the problem in your thinking, you are stuck on the Old RAD
>> thinking. You need to free your mind. It is a bondage.
>> 
> I understand. But just because you have moved to MVP and are stuck
> with it is not a valid argument.
> 
>> I losted some years not recycling myself. Get a good book of MVP,
>> start learning the Gang Of 4, not that I am pattern freak, you need
>> to use what is better for the situation, however since programs grow
>> and fast you need to learn from experince, from others..
>> 
> All that has happened is you've gone from RAD to another purist view.
> Here is the difference in our opinions. I don't want the framework to
> drive the ux. I want the ux to drive all the development.
> 
>> I do not advocate RAD anymore, neither SQL centralization
>> 
> I advocate giving the user the best experience possible then worry
> about the approach needed to accomplish that. We're getting a bit off
> topic. The most important thing at this point in our discussion is
> that RAD is not the framework. It is just the drag-n-drop. You can
> apply drag-n-drop to any number of different frameworks.
> 
> Sometimes a browser like approach is good. Like with these NGs. I
> don't want to keep data on my local machine to read and post here. But
> if you have a situation where a user *must* complete their work in the
> field with or without being connect. Then an approach that requires a
> connection is inferior.
>

> {quote:title=Eduardo Elias wrote:}{quote}
> 
> Based on your comments you seems to be old Delphi RAD guy somewhere Delphi 
> 2 or 3  ;)

Yes I started with Delphi v1 doing RAD stuff. Then I went through all the "code it up" undulations that most go through. Now as I look back on my older stuff. Some of it running 10+ years without changes. I wonder if all those efforts to be purist were really worth anything more than learning what else is available.

> Depends of what you call smaller systems. Many programs? Classes? What?

Well most everything. One big program or one big unit or one big class isn't good. Look at mobile apps. If people would have created a dedicated data module for each form or master form. Something many here suggested against, myself included, at one time or another. The dev could easily pull out the dm and the related forms then with a little tweaking compile a mobile app. Now that's an awesome way to move a system to mobile! But with not wanting to use duplicate data set components and trying to reuse da
ta modules across forms you have to more or less create a new mobile app from scratch. Or you have to untangle the connections. In other words the redundancy of the beginner is now a benefit.

> Are you sure you using Delphi all these years?

Yes I'm fairly certain of it. Unless the world I live in doesn't actually exist. :-)

> You are talking like Client/Server stuff.

I know the MVC approach. But I'm saying. Don't get stuck thinking about being a purist of one or another approaches for this discussion. Think first the user then worry about the implementation.

> Central location is not a server. Try reading some MVP, MVVM or MVC stuff 
> and you will understand the differences on how to separete the layers

I understand those. I thought you were meaning one server.

> Right now I am sucessfully using VCL FMX and UniGui, 3 different frameworks, 
> with the same software. I need only to rewrite the View (the form). There 
> is no code at all on the view.

So what kind of logic do you include with a mobile app? For example... If the mobile app user is entering some data and the business rules require all first letters of words to be capitalized. Must the mobile app post the data to the server *before* it will check the business rule of first letter capitalized?

> User experience has nothing to do with the choosen 
> framework. User experience needs to be best always.

I think user experience is impacted by the framework sometimes. I agree that the ux should always be best. Like for example when using a browser app and I can't do any work because the internet went down. That's not the best and the framework causes that.

> There is nothing related to centralized server here. If you learn MVP for 
> example you will see that.

I understand MVP. You're just proposing that it's the best. I'm not making that assumption.

> I have a ORM layer to deal with SQL.

I like ORMs.

> the Model contacts the server for data.

But, again, where is the ux logic? Do the screens the user interacts with need to post to a remote layer for all logic or is there logic on the mobile device?

> When you get close the user things are easier.

But are they as robust? Can the user see a violation of the rules before they've finished a large screen and then posted their work?

> The logic is spread. Each place with the rules that are appropriate. but 
> not in the form

So when are the rules applied? Can the user still run the app without being connected and sync when the connection is back?

> I am serving my own interstest that is giving the best to the user with the 
> better from programming.

But if the user must be connected to find out if what they are doing follows the business rules then I would contend you're serving the programmer and not the user. The user should not have to be connected 100% of the time to work.

> I dont understand what is your problem, seems that you learned to count 1, 
> 2, 3 and anything different of that causes fear.

I would contend here that you only want to accept MVP.

> Here is the problem in your thinking, you are stuck on the Old RAD thinking. 
> You need to free your mind. It is a bondage. 

I understand. But just because you have moved to MVP and are stuck with it is not a valid argument.

> I losted some years not recycling myself. Get a good book of MVP, start learning 
> the Gang Of 4, not that I am pattern freak, you need to use what is better 
> for the situation, however since programs grow and fast you need to learn 
> from experince, from others..

All that has happened is you've gone from RAD to another purist view. Here is the difference in our opinions. I don't want the framework to drive the ux. I want the ux to drive all the development.

> I do not advocate RAD anymore, neither SQL centralization

I advocate giving the user the best experience possible then worry about the approach needed to accomplish that. We're getting a bit off topic. The most important thing at this point in our discussion is that RAD is not the framework. It is just the drag-n-drop. You can apply drag-n-drop to any number of different frameworks.

Sometimes a browser like approach is good. Like with these NGs. I don't want to keep data on my local machine to read and post here. But if you have a situation where a user *must* complete their work in the field with or without being connect. Then an approach that requires a connection is inferior.

one of the two: or i could not express myself, or you totally not understand 
what I said !!

Based on your comments you seems to be old Delphi RAD guy somewhere Delphi 
2 or 3  ;)


>> I wrote them a big ERP that uses one centralized DataModule. And each
>> form when opened creates an instance of it. On the form I have a
>> DataSource of the tables needed connected to the datasets on the
>> Datamodule.
>> 
> That's another thing about sharing too much. The one centralized
> system becomes huge. Supporting every situation that can be thought
> of. Then if the situation changes the centralized system is so tangled
> that it's very difficult to change. But having different smaller
> systems makes it easier to replace any of the smaller parts.

Depends of what you call smaller systems. Many programs? Classes? What?

> 
>> After some other years, I have realized that RAD is a dangerous
>> thing. Very dangerous.
>> 
> I think your equating RAD to something its not. RAD is just the
> drag-n-drop visual environment. The component framework can be
> implemented in many different ways. In other words I can create a set
> of components that implement any custom framework but until I make
> them drag-n-drop they are not RAD.
> 

I am saying what RAD was in the first versions of Delphi. I bought Borland 
Pascal 6 that came with the very first Delphi 1 with it

It is all there, how to be RAD. Place a button on the Form, click twice and 
write the code !!!!  Are you sure you using Delphi all these years?

>> I know some companies that today are in big trouble because
>> developers only followed the original Borland idea, and still around
>> with some of the old guys of the team.... of double clicking a button
>> and adding code right there.
>> 
>> But you should not have ANY code on the view.
>> 

> That's extending things completely in the other direction. Logic in
> the form may be just where it should be. Having it in some central
> location loads up the back end. If you can send particular logic to a
> user in a form when that user(s) need it why keep it *only* running in
> a central location? I remember the fear developers had about making
> sure, for example, data is scrubbed correctly before storing it to the
> database. But I've always thought it was bad that the user is forced
> to wait until they try to apply their work before they get an error
> message about something they then have to *go back to* and fix. Having
> all the logic centralized makes things much easier for the programmer
> but then the user suffers.
> 

You are talking like Client/Server stuff. Wrong.

Central location is not a server. Try reading some MVP, MVVM or MVC stuff 
and you will understand the differences on how to separete the layers

See, one thing is to have a server with data and logic. Other thing is how 
you manípulate this and show this on your forms.

Right now I am sucessfully using VCL FMX and UniGui, 3 different frameworks, 
with the same software. I need only to rewrite the View (the form). There 
is no code at all on the view.

I can even implement partially the view in another framework, since the process 
of control understand that.

You are confunsing things. User experience has nothing to do with the choosen 
framework. User experience needs to be best always. If not you failed as 
programmer. If you solelly rely on whatever you writing you failed. You need 
to structure your software creating your framework first.

>> true OOP needs to have some use of a framework created to hold your
>> data and rules.
>> 
> The problem is with the world becoming so interconnected you cannot
> run one big server on an island centralized to everyone. This means
> logic must be *sent* to the user where it can be used. If you have
> rules on the server but someone wants to save data locally for a bit
> then they either need the rules locally or they will save erroneous
> data until it gets applied to the central server. That doesn't sound
> bad except in situation
s where the user acts upon the data they have
> locally before it gets applied t


There is nothing related to centralized server here. If you learn MVP for 
example you will see that.

My logic is spread over the structure of my software, but in a way that each 
layer only holds what is concerned for it. I dont use SQL server as a business 
logic centralizer. I know  you can do that, and almost write an entire software 
based on SQL stored procedures and triggers.

My use of SQL is just plain. I have a ORM layer to deal with SQL. My software 
has NO SQL AT ALL. But uses it, even queries. No more nightmares with those 
strings with sentences, that once you change the database you need to go 
across everything to change senteces strings. Take a look on Aurelius you 
will see.

> 
> o the central server where it is found to be erroneous.
> 
> Take for example mobile apps. They contain the logic for people to do
> their work. They are not just a *view screen*. And they are being used
> more and more everyday.
> 

Again, the thinking is not cliente/server only. This is basic. You do have 
on the software Model, Viewer and Presenter. Each one doing its part. And 
the Model contacts the server for data.

In my case my model Layer, uses Aurelius, that uses XData on the server side, 
that is using Aurelius to create the bussines logic in the server side and 
then finally the SQL Server.

All these layers reduce the complexity of each other layer. When you get 
close the user things are easier. But again the view is nothing, it is just 
a view, the presenter is what asks the model for data and gives to the view 
on the right place.


>> Datamodule is not that. I still use datamodules, to place some
>> DataSet and give what is needed for the visual part of RAD works. But
>> there is no code and no use of events or anything on the datamodule.
>> Just a fancy centralizer container.
>> 
> So where is the logic? On the central server? And, if so, how do
> people who save data locally know their data doesn't fit in with the
> centralized rules before the post the data to the server?
> 

The logic is spread. Each place with the rules that are appropriate. but 
not in the form

>> For a simple coffe shop Rad application, it takes 10 times more work
>> and time to develop... however anything serious that needs to grow
>> and changed frequently, new versions across the years, it is the way
>> to go.
>> 
> But are you serving the programmer or the user?
> 

I am serving my own interstest that is giving the best to the user with the 
better from programming.

>> I have my view totally isolated from the code, at point that i have
>> different views for different platforms using the same (presenter)
>> code.
>> 
> What is the user's experience? Are they getting the most features
> where and when they need them?
> 

I dont understand what is your problem, seems that you learned to count 1, 
2, 3 and anything different of that causes fear.

Software is something you create the way you want. If you have a bad experience 
for the user is because you wrote that way. So go there and write it correctly


>> For me took some time to rewire my brain and forget the old delphi
>> style. I am now seeing that is a good thing.
>> 
> I'm not sure exactly what you consider the old Delphi style. But if
> you think of forms, even ones with a corresponding data module, to be
> like mobile apps. How will the user get *any* features to use if there
> is no logic in the forms or the data module?
> 

Here is the problem in your thinking, you are stuck on the Old RAD thinking. 
You need to free your mind. It is a bondage. 

I know I have been there.

I see people back on 2004 talking about crazy stuff like MVP and I did not 
understand. Those where crazy people.

I losted some years not recycling myself. Get a good book of MVP, start learning 
the Gang Of 4, not that I am pattern freak, you need to use what is better 
for the situation, however since programs grow and fast you need to learn 
from experince, from others..

I do not advocate RAD anymore, neither SQL centralization, I think that there 
are different concerns and n-tier is that. But do not think about "modules", 
it is most of the time "classes", layers of classes in your framework. My 
software is basically Client/server if  you see it far away, if you get closer 
you will see litlle more layers. But inside it the thing changes a lot.

David Cox wrote:

> > {quote:title=Peter Below wrote:}{quote}
> > David Cox wrote:
> > 
> > > I tried changing the data module to use .Create(Self) in the
> > > FormCreate and it did not resolve the issue.  I still need to
> > > reassign the controls to the data source.  So I am still stumped.
> > 
> > If you bind db-aware controls to a datasource/dataset *at
> > design-time* then the form with the controls on it will only work
> > as intended at run-time if the datamodule containing your dataset
> > already exists when the form itself is created. The form resolves
> > the references to the datamodule (which the designer has stored
> > into the form resource) by looking for the datamodule in an
> > application-global list (Screen.Datamodules) *by name* (value of
> > the name property of the datamodule). If you try to use one
> > datamodule per form and still use design-time binding you have to
> > 
> >  - override the form's constructor (using the onCreate event handler
> > will not work, it executes too late!)
> >  - create the datamodule instance before you call the inherited
> > constructor
> >  - call the inherited constructor (which loads the form resource and
> > resolves the references to the DM)
> >  - the set the Name property of the datamodule instance you created
> > to empty.
> > 
> > If you don't do this last step the next instance of the form you
> > create will bind to the already existing datamodule, not the one
> > you created for it.
> > 
> > 
> > 
> > -- 
> > Peter Below (TeamB)
> 
> Hi Peter,
> 
> What you say makes sense, however if what you explain is true, why
> does the follow work (and it shouldn't):
> 
>    Form1 (creates Form2)
>    Form2 with dmModule.Create(self)

Have you verified that the datamodule is not autocreated? That is the
default...


> 
> The Form2 data module has a data source that is linked to a data
> aware combo box on Form2.  This should fail as the data aware
> controls are set to the data source at design time, but it works.  As
> soon as I create the same data module in Form1, that's when it fails.
> 
> One easy way around this problem is to add a data source to each form
> that will be using the data module, bind the data aware controls to
> the form's data source, and then during the FormShow set the local
> form's data source's data set to he data module's date set.  This
> requires a data source on each form that will have data aware
> controls, but adds nothing to maintaining the data module.  I am
> leaning towards using this solution.

Yes, that is a good solution.



-- 
Peter Below (TeamB)

> {quote:title=> Rich < wrote:}{quote}
> > {quote:title=David Cox wrote:}{quote}
> > 
> > One easy way around this problem...
> 
> There you have it. Now you can move on and add more features!

Right on!

> {quote:title=David Cox wrote:}{quote}
> 
> One easy way around this problem...

There you have it. Now you can move on and add more features!

> {quote:title=Peter Below wrote:}{quote}
> David Cox wrote:
> 
> > I tried changing the data module to use .Create(Self) in the
> > FormCreate and it did not resolve the issue.  I still need to
> > reassign the controls to the data source.  So I am still stumped.
> 
> If you bind db-aware controls to a datasource/dataset *at design-time*
> then the form with the controls on it will only work as intended at
> run-time if the datamodule containing your dataset already exists when
> the form itself is created. The form resolves the references to the
> datamodule (which the designer has stored into the form resource) by
> looking for the datamodule in an application-global list
> (Screen.Datamodules) *by name* (value of the name property of the
> datamodule). If you try to use one datamodule per form and still use
> design-time binding you have to
> 
>  - override the form's constructor (using the onCreate event handler
> will not work, it executes too late!)
>  - create the datamodule instance *before* you call the inherited
> constructor
>  - call the inherited constructor (which loads the form resource and
> resolves the references to the DM)
>  - the set the Name property of the datamodule instance you created to
> empty.
> 
> If you don't do this last step the next instance of the form you create
> will bind to the already existing datamodule, not the one you created
> for it.
> 
> 
> 
> -- 
> Peter Below (TeamB)

Hi Peter,

What you say makes sense, however if what you explain is true, why does the follow work (and it shouldn't):

   Form1 (creates Form2)
   Form2 with dmModule.Create(self)

The Form2 data module has a data source that is linked to a data aware combo box on Form2.  This should fail as the data aware controls are set to the data source at design time, but it works.  As soon as I create the same data module in Form1, that's when it fails.

One easy way around this problem is to add a data source to each form that will be using the data module, bind the data aware controls to the form's data source, and then during the FormShow set the local form's data source's data set to he data module's date set.  This requires a data source on each form that will have data aware controls, but adds nothing to maintaining the data module.  I am leaning towards using this solution.

Thanks for your help,

Dave

> {quote:title=David Cox wrote:}{quote}
> Well I jumped the gun thinking that creating the module with Self would resolve the issue; it does not.

If I'm understanding what your explaining I think you need to do this (not actual code just an explanation):

DataModule1.Create;
Form1.Create;
Form1.Show;

DataModule2.Create;
Form2.Create;
Form2.Show;

Or if it is your main form then you just set the data module to be created first in the project settings.

Keep in mind I haven't written much Delphi code for a few years but I did use it for many years before that. I think you're trying to package your data modules and your corresponding forms together. You're wanting the form to know which data module it needs and to create that when it needs to. Again "intelligent forms."

I'm not a programmer anymore. I'm a software developer. So I too focus on user features. But I've fought through all the purist stuff over the years. These guys here know their stuff but you need to ensure you explain you're not creating the all encompassing world changing do all be all platform.

Also if you need help and you're in the US let me know and I'll give you my contact information for direct help.