Dialog in DLL

[Michel Posseth [MCP]]

Yes, my reference is from COM and COM+ DLLs, back in the day. But on the

other hand, there would be no way I would do something of the sort with a
.NET solution either. That is popping Windows forms from a DLL. It's
ridiculous.

Euhhhhh :-(

Hello here i am a person who works with forms from Dll`s

I can tell you that it in fact is pretty handy if you have a hughe project ,
where diverse data is bound to common keys , we now only have to develop one
search dialog for every key value pairs .

By the way i have in the past written a VB6 app wich could give it`s
complete GUI to a calling application , and yes this was with COM you then
had to write a ActiveX executable to acomplish this , so also with COM
this is possible however not from a dll

I found this new possibility pretty inovating and do not see anything wrong
with it , i only see new posibility`s and it saves me a lot of extra coding,
the one thing i am missing in .Net is a substitute for a ActiveX executable
where you could give over the form in a out of process way

regards

Michel

 

[Mr. Arnold]

Why? What if you have some forms which are used by different forms, such
as a login dialog, an item selection dialog, a custom print preview
dialog, ...? I think it makes perfect sense to place them in a library.
However, then I would not use late-bound access.

You see this is where developers start going wrong. I have been programming
business solutions since 1980 and went to the MS platform in 1996. One
should keep things as simple as possible and not over complicate things,
which makes them maintainable, makes them solid program solutions and makes
them scalable solutions.

I have run into too many solutions where the programmers just did what they
wanted to do with no regard to simplicity. Everyone of those solutions were
just complicated and un-maintainable trash.

I just came off of a contracting project where the huge Windows
desktop/MVP/WCF solution being implemented was/is a total nightmare and will
continue to be a total nightmare for the company, because the programmers
went wild with .Net technology. The thing is bleeding badly where they
called the tracking solution to keep track of user problems/incidents
Triage, because the overall solution is too complicated with over
complicated coding that just leads to problems.

So, no I would never do it or allow forms to be popped from DLL(s) if I have
anything to do with it.

I am sorry. My motto is the simpler one can make it the better things will
be overall and putting forms in DLL(s) is unnecessary complication.

 

[Mr. Arnold]

Euhhhhh :-(

Hello here i am a person who works with forms from Dll`s

I can tell you that it in fact is pretty handy if you have a hughe project
, where diverse data is bound to common keys , we now only have to develop
one search dialog for every key value pairs .

By the way i have in the past written a VB6 app wich could give it`s
complete GUI to a calling application , and yes this was with COM you
then had to write a ActiveX executable to acomplish this , so also with
COM this is possible however not from a dll

I found this new possibility pretty inovating and do not see anything
wrong with it , i only see new posibility`s and it saves me a lot of extra
coding,
the one thing i am missing in .Net is a substitute for a ActiveX
executable where you could give over the form in a out of process way

regards

See my other post

 

[Michel Posseth [MCP]]

Hello "Mr. Arnold"

If i read your story , i say okay ! i fully concur with it however i wonder
what you find complicated about "popping" forms from dll`s
in my homble opinion it rather simplify`s application design cause now you
can really create a modular design even with Forms .

In my case for instance this aproach saved me thousands of lines of code

Michel

 

[Herfried K. Wagner [MVP]]

So, no I would never do it or allow forms to be popped from DLL(s) if I
have anything to do with it.

I am sorry. My motto is the simpler one can make it the better things will
be overall and putting forms in DLL(s) is unnecessary complication.

Well, I agree with your motto and I believe that many "software architects"
produce over-architected and dysfunctional crap. However, I disagree with
your opposition to placing forms in DLLs. Some DLLs in the .NET Framework
contain forms, and this makes sense if they can be reused in different
applications based on the DLLs. This is a good solution in general because
it prevents code duplication. The downside of this approach is that it also
prevents further development of the forms which would break the
semantics/usage context of one of th client applications using the DLL.

 

[Herfried K. Wagner [MVP]]

Just to take this discussion a little further ... what would be the best
way to post a message back to the calling exe? For example, after the
dll did some work, what if it wanted to tell the calling exe to refresh
its window?

First, I am wondering why you would want to use reflection to access the
DLLs. Are you planning to write an extensible application?

Second, you can raise an event from within the form to notify a client about
the occurance of an event. To do so, you could define interfaces or base
classes containing the definition for the event, which the forms in the DLL
implement or inherit from. Using this approach you could write the code to
access the form as usual.

\\\
Dim f As IEntryForm = _
DirectCast(<object created via reflection>, IEntryForm)
AddHandler f.Submit, AddressOf ...
DirectCast(f, Form).ShowDialog()
///

 

[Herfried K. Wagner [MVP]]

Could you give an example when not ?

Sorry, my mistake. I mixed it up with setting the form's owner form.

 

[Mr. Arnold]

Hello "Mr. Arnold"

If i read your story , i say okay ! i fully concur with it however i
wonder what you find complicated about "popping" forms from dll`s
in my homble opinion it rather simplify`s application design cause now you
can really create a modular design even with Forms .

It may be applicable in some situations. But on the other hand, if one has
to make changes to base code such as this to accommodate it being
implemented into other solutions (and that happens more than one thinks it
will happen), then IMHO code such as that should be avoided.

In my case for instance this aproach saved me thousands of lines of code

If you're the only one that has to maintain it then that's ok. But again,
this is where I feel many developers of this era make their mistake in not
thinking about those developers that will maintain the solution, which
should be an attempt to keep things as simple as possible. Most of them
don't do it, only think about their immediate development needs, and they
are totally oblivious to anything else.

I guess I come from a different era when I learned to program and develop
business solutions, which has served me well over the years. The simpler it
will be the better it will be.

I just feel that what you're talking about is complication, which is not a
totally a bad thing (complication) and is warranted in some cases, but I try
to avoid it.

 

[Jack Jackson]

On Sun, 15 Jun 2008 17:03:28 -0400, "Mr. Arnold" <MR.

It may be applicable in some situations. But on the other hand, if one has
to make changes to base code such as this to accommodate it being
implemented into other solutions (and that happens more than one thinks it
will happen), then IMHO code such as that should be avoided.


If you're the only one that has to maintain it then that's ok. But again,
this is where I feel many developers of this era make their mistake in not
thinking about those developers that will maintain the solution, which
should be an attempt to keep things as simple as possible. Most of them
don't do it, only think about their immediate development needs, and they
are totally oblivious to anything else.

I guess I come from a different era when I learned to program and develop
business solutions, which has served me well over the years. The simpler it
will be the better it will be.

I just feel that what you're talking about is complication, which is not a
totally a bad thing (complication) and is warranted in some cases, but I try
to avoid it.

Yes, certainly putting this (or any other code) in a DLL to be used by
multiple projects does tie all of those together and may cause trouble
in the future if changes have to be made to the common code. I don't
see how displaying forms in a DLL is special in this regard. Don't
you put business logic in DLLs that are shared, and wouldn't that
possibly cause problems if it has to be modified later?

What alternative is there other than duplicating the code in multiple
places, which has its own set of problems? Usually I would rather
share the code.

 

[Michel Posseth [MCP]]

Exactly my point , for me a forms class is just like anny other class if i
can create it in such a way that it might be usefull in other projects i put
it in a library

michel

 

[Mr. Arnold]

On Sun, 15 Jun 2008 17:03:28 -0400, "Mr. Arnold" <MR.


Yes, certainly putting this (or any other code) in a DLL to be used by
multiple projects does tie all of those together and may cause trouble
in the future if changes have to be made to the common code. I don't
see how displaying forms in a DLL is special in this regard. Don't
you put business logic in DLLs that are shared, and wouldn't that
possibly cause problems if it has to be modified later?

No, I don't put business logic in code that is shared by other projects.
Some developers do try to implement that in solutions *common business
logic*, but to be honest, the *common business logic* doesn't exist from
what I have seen over the years. The *common business logic* is usually
dedicated to the original solution and goes no further.

The only solution I have seen that was used across solutions by means of a
DLL or DLL(s) is an in-house written database engine used by the DAL of all
developed solutions, which worked very well.

What alternative is there other than duplicating the code in multiple
places, which has its own set of problems? Usually I would rather
share the code.

If that's the way it needs to be to keep things separated and keep it simple
particularly so in business logic, then it may need to go in that direction
(code duplication) to keep things simple. Code duplication (code that is
duplicated from one project to another) has not gone anywhere and is still
viable and being used. There is nothing wrong with it.

Note: I am not talking about duplicate code in multiple projects in the same
solution.

I don't have anything against what you are talking about. I just learned log
ago to keep things simple and non-complicated in order to implement business
solutions that are viable and successful -- no complications that are not
justifiable.