Re: Forms vs Dialogs - A Question of Architecture - Design and Architecture Discussion Boards

the point of it was so the people who use the .hnh dose not have to copy 7 files, just 1 .hnh if that make more sence

If at first you don't succeed
Redefine success

J.Hardy

modified on Tuesday, April 21, 2009 10:05 PM

Can you package the files together in an installer, and have the user install the program? That way all the need to copy is setup.exe, run it once, and then access the program from the start menu or application menu, or desktop shortcut, or whatever.

Dybs

i would like to avoid the installer if possible, i would like them to be able to copy the .hnh file from computer to computer without installing it

If at first you don't succeed
Redefine success

J.Hardy

I don't think you can do that, as far as I recall is only .EXE and .COM files can be executable in Windows/DOS (going all the way back to the beginning of time).

I have seen something similar done that is the opposite of what you're describing. Where-in you have an .exe "program" that is labeled as such, and it stores or has extra data written to it after then end of the executable code. So basically the file structure on the drive looks something like this:
"[exe header][exe executable code]||[extra data]".exe

This way, the OS can run the file, as the header, entry point of program, and all executable code addresses are retained, while the data that needs to be accessed is appended to the end. It would be up to the program to track where the end of the code was for instance:

Const FixedProgramLength = (an integer that represents how many bytes the exe code is)
Const StartOfDataAddr = FixedProgramLength + 1

The only other way I could think of to make a .hnh file executable would be to make an axillary service that would be running prior (at startup) and somehow initiate the executable code stored within. (Similar in concept to Java .jar files, in that without the Java Runtime library installed and running the OS doesn't know that it's a program of any kind).

However, I would venture that the first solution would be the easiest... And besides, as mentioned, there's no good reason that a program should have a different extension that isn't unethecal

that sounds great! could you point me to some articles on how to do that please (first solution)

If at first you don't succeed
Redefine success

J.Hardy

After a break to clear my head and read some more, I'm back to trying to develop a simple database program for my own use at work. Rather than continue with my previous project, I'm starting fresh.

The problem - track the purchase, installation, maintenance, and movement of three types of equipment for a power company. Simple, right? I thought so, but maybe not simple enough for me yet.

One approach I tried was to have the user select one of the main functions - Add, Edit, Move, Service - from the main form, then use hide/show to move to a subform for that function. My thought at the time was to then use a string of dialog boxes to walk the user through the selection of the target equipment, enter the data required (it changes depending on the equipment type), then return the data to the subform for updating the database. In my thinking, that would make it easy to simply "Add another?" from the base subform. That got rather complicated, and I got lost.

The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions. I just have no idea how to implement it.

At the moment I have a nice Main form with a side-panel menu, a .mdb database file with sample data already loaded, and a very attractive company logo in the top left corner. I also have a nagging feeling that I'm missing something important in a conceptual way, something that hours of studying MSDN and C# programming books isn't helping. The simplistic examples used in most books aren't very useful for learning how to do real world tasks - sample programs have one Form, dialogs do only one thing, then close, etc...

I've found that what I can learn from three or four helpful posts here usually exceeds what I can glean from a month or more of study, so I thought I'd give it a shot. Last time I did I received several very helpful tips that helped me a lot, and I appreciate them all. I also got a few snide, insulting comments from a few who are very active, but whose histories show that they've never once posted anything else. I've been here a long time, and I'm immune to those.

Thanks, in advance, for any helpful suggestions as to how I should structure this solution to make it as painless for me - a tyro - and as efficient as is practical for a beginner. I'm eager to learn, and it's going to make my job a hell of a lot easier if I can get this working. I'm doing it on paper now, and it's a time vampire.

"A Journey of a Thousand Rest Stops Begins with a Single Movement"

Reading you was like remembering some past adventures in programming. I remember on several occasions thinking that it was just a simple solution and it turned out not to be. For myself I just stopped thinking that, pretty much ever.

That said for a nominally complex software project starting at the beginning means requirements or functional specifications, at a minimum in the form of Use Cases.

Again for a small project, you then run those through some scenarios. This results in people (in this case it sounds like you are on your own, not sure) gaining a clearer picture of the realities and a level of confidence that the requirements are complete enough to begin working on things like UI design prototypes, application architecture and finally the OO Design.

You might find this series of articles[^] helpful.

As always, an excellent piece of writing from Joel... Thanks for the link! It doesn't actually address my quandry, but it's a great reminder that some things never change. I was weaned on DOD-STD-2167 and MIL-STD-490, using type B5 specs. They were a pain to implement, especially for a young programmer chomping at the bit to start coding. Unit Design Folders and Interface Control Documents were a way of life, and though they weren't the fastest way to market, they remain the fastest way to market with a product that actually works. That's probably the root of my frustration with Microsoft - the shortcuts they take to be first on the shelf are the direct cause of their complete failure to release products that work correctly out of the box. The other point Joel touches on, however indirectly, is the need for technically adept tech writers, and clear documentation. Not just for the spec, but to provide pre-emptive customer support in the form of usable help and printed manuals. That was another invaluable concept killed by Microsoft.

In my old age I tend to take shortcuts - no formal specs, just a written description of what the program must do. Along with that I hand craft every screen on paper, naming each control and assigning an appropriate data type to each if it has a member that must be manipulated. I also love flowcharts - I use them in my day to day work, even though it has nothing to do with software. Every task - running errands on a weekend, for instance - can be improved by writing down the flow and optimising it to make efficient use of every step. My flowcharts start out at the top level - no detailed steps, just a written visualization of what a user would do with the program, with big blocks that contain "Do something useful and save the changes somewhere." Later I expand the blocks into their own flowcharts, constantly reducing until I can almost code each block in a line or two.

That works great if I have a clear idea of how the overall program structure should look, of what techniques are easy to implement and which are okay but tedious. There always exists more than one way to accomplish the job, but some ways are smarter than others. The architecture is critical, and that's what I was asking about. Yeah, I'm on my own here, which is why I'm asking. I've lived here 16 years and never met another person who can make a computer say "Hello world" without typing it in Word. Sigh | :sigh:

"A Journey of a Thousand Rest Stops Begins with a Single Movement"

Roger Wright wrote:
The architecture is critical, and that's what I was asking about.

Couple things

Roger Wright wrote:
user select one of the main functions - Add, Edit, Move, Service - from the main form

User selects from Menus and toolbars, not forms.

Roger Wright wrote:
The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions.

The problem with that section is that you are coupling the UI design to the Code design. This is not correct. Arrive at a UI design from considering usability. The problems with code design are not related to UI design.

Now let's talk about the last part of that section.

Roger Wright wrote:
There ought to be a single point of control for the data access, a separate layer that is common to all functions.

Yes, that and many other Software Design Patterns are already common knowledge. This statement can only have us conclude that you are not yet studied enough in design and patterns to understand the solutions to these problems. Furthermore trying to cover all that ground in an internet forum reply is not an appropriate reaction.

My advice is that you stop development and continue with your studies of design and patterns. As you learn well known design principles and patterns you will recognize some of them as solutions to your current problems. Well at least that's how it works for me. Wink | ;)

In case you have not seen these folks ( there are many others as well) here is where they share their expertise:

Martin Fowler[^]

Ward Cunningham[^]

It seems not so complicated a project for you to design for. Now that you have three types of equipment, why not design three different forms for each type?It's no need to construct a perfect design in one project,at least not for this one ,right?To achieve your goal is OK,right?

Regards,
Dealon

Impossible is nothing!

Hello All,

Just wanting to ask about class methods in OOP / 3 tier layers.

How do you determine where the methods reside in a class, with reference to the Business Logic Layer.

I am very confused about this.

Any help would be great. Thanks

CrimeanTurtle2008 wrote:
I am very confused about this.

Then you need to be reading materials on the subjects rather than posting things in internet forums. I guarantee your progress will be like 10 fold faster. Big Grin | :-D

Hello,

I'm making an email client as a homework.
Its supposed to have multiple account support, contacts, etc.

But im in a discussion with another person about an OOP thing,

We have the class "Message", and it contains the fields from, to, bcc, cc, and of course others, but this problem is focused on those fields.

Considering that:
-A message can contain multiple emails in the to, bcc, and cc field.
-For whatever reasons we have the classes Account and Contact

One approach:
To have all these fields of type string, that is:

from : string
to : List< string >
bcc : List< string >
cc : List< string >

Second approach:
To have the class Person (with the fields name and email) which is a generalization of Account and Contact, that is:
Account extends Person
Contact extends Person

And in the class Message, to have these fields of type Person, that is:

from : Person
to : List< person >
bcc : List< person >
cc : List< person >

I would go for the second approach but the other person insists on going with the 1st choice, and I don't know how to convince it, and to convince myself that i'm right.

SORRY BAD ENGLISH!

Wouldn't the Person class support multiple email addresses too? I have several.

How about an IAddress interface (I have no idea what it may contain) which EmailAddress (and others) implements.

Person can then have a List<IAddress> and some instances of Person may contain instances of EmailAddress and an email message will use List<EmailAddress>

You may also want to look at the classes in System.Net

So the big question has to be: Why do you think your approach is right? If you can't convince yourself its the one to go with, you'll have a job convincing someone else. To make it easier to come up with an answer use just the 'to' as an example as the other lines, bcc, cc etc are similar. What do you get, if anything, using Person that you don't get using String? Or conversly: What do you get using String that you don't get using Person? If there is a difference here, Does the user of the email system you are designing want whatever benifits that difference brings?

What do I get using Person that I don't get using String:

That future operations will be easier because of treating with an object person than a string, for example searching, or showing the person info (lets say a picture, or the fullname, or whatever) when reading the message. Of course I can do that too if those fields are strings but I think i would have more hardcoding instead...

Am i right? also conceptually I would have object connections between a person and a contact, which wouldnt be that explicit if those fields where strings

Thats why I defend the Person class

Hi,
That future operations will be easier because of treating with an object person than a string..

Leaving aside whether these future operation will be easier this way or not for a second, it's homework - you've only got a limited amount of time to design and code a limited amount of features. So you really need to decide what those features are before coding i.e What are you going to do. Only after that, decide how to do it. Just like any Project - homework or otherwise.

For example searching, or showing the person info (lets say a picture, or the fullname, or whatever) when reading the message...
Searching for what? You have do decide befor starting the coding.
Are you going to want to display a picture for every email you read? You won't have one for most of the spam you get!
Do you have to display the fullname of every email you read? Again a lot is junk so you won't be able to for everyone
'Or whatever': The 'whatever' bits derail lots of projects because nobody has decided what features are being aimed at, they've just sat down and started coding.

A message can contain multiple emails in the to, bcc, and cc field

Decide exactly what a message is. Is it an email (rather than multiple emails) with multiple addresses rather than multiple emails?

Of course I can do that too if those fields are strings but I think i would have more hardcoding instead...

to be honest I'd say its hard to tell how much coding will be needed either way at this stage. Though I see what your point is.

Am i right? also conceptually I would have object connections between a person and a contact, which wouldnt be that explicit if those fields where strings
One of the biggest slip-ups I see, and which I made, when starting OOP is to have all the objects dependant upon (know about) one another. Object A knows about object B which knows about C, D, E etc and when you want to make a little change to one it affects them all and gets complicated.

Get used to thinking what the User wants. If the User wants stuff like being able to hover their mouse over an address in an email and have details pop up, it may be that being able to link that address to the Person object will be handy.

I'd think of another object or just code that combines other objects - The-email-editor as well. This could do the hard work of linking addresses to Persons, and could keep the Message and Person objects separate.

Sorry if I'm not saying Yes/No you should use the Person class, but its your homework after all and I'm just trying to make you think of some of the reasons why you would decide Yes or No. One definite thing is, that by being able to code Person without knowing about the design/code of Message and vice-vera you have an advantage.

Sorry if I'm not saying Yes/No you should use the Person class, but its your homework after all and I'm just trying to make you think of some of the reasons why you would decide Yes or No. One definite thing is, that by being able to code Person without knowing about the design/code of Message and vice-vera you have an advantage.

Thanks for replying.
I think you summarize my whole point of view in your last paragraph.

About what a message is, maybe I messed up things when saying "a message can contain multiple emails in the to, bcc, cc fields", i was referring to "multiple addresses".

Quake2Player wrote:
What do I get using Person that I don't get using String:

I don't know, how are we supposed to know that, we don't have your requirements nor your design documentation. You know things like Use Cases and CRC cards.

You say you are a student, do they have you learnCRC Cards[^]? If not you should.

Notice item #3 "The responsibilities of the class."

Responsibility is key in determining design and the answer to your question "what do I get".

For not making another topic, I have an encapsulation debate with myself:

Account contains List< Contact > and List< ContactGroup >, and methods to manage these..

How should I DECIDE if I should encapsulate all the contacts classes and methods in lets say an AddressBook class?

The same for other things contained in Account, like all concerning Messages: List< Labels >,List< Messages >, List< MessageThread > and methods..

My great question would be that if I have a lot of encapsulation, then I would have a lot of inbetween methods, from the main application to the object itself, like...
Application.AddLabelToMessage()
calling Account.AddLabelToMessage(msg, label)
calling MessageManagerOrSomething.AddLabelToMessage(msg, label)
calling certain Label as Label.AddMessage(msg)

Please have patience, i'm learning to model well (I know these can be done either way)

Again sorry bad eng.

How should I DECIDE if I should encapsulate all the contacts classes and methods in lets say an AddressBook class?

Does the word ('AddressBook' in this case) come up often (preceded by 'the') when you talk or think about the design and how to do it? If so it's probably a good contender to be an object. Then, consider if you can come up with messages (methods) such as Set...., Get....., Do....., that you would use on this object to have it do things.

Should one class contain other classes?
Ask: "Does Class1 have a Class2 OR Is Class1 a type of Class2, if its the first one, Class 1 should contain Class2.

Consider your: List<messages>, what happens if near the end of your coding you decide to change to, say vector<messages> or String Messages[50]. If you've written a class CMessages with methods, say, GetMessage(...) and AddMessage(..) which encapsulate this, then it's no problem. If youve used list here there and everywhere in the code it can be a real problem to change them all.

a lot of inbetween methods?
Being able to call Application.AddLabelToMessage(...) is probably better than needing to use four or five lines to get one object, then another from that, then another from that and finally to call, say, MsgHeader.AddLabel. You don't want to bother low level objects like, say, MsgHeader objects at a high level. Just calling AddLableToMessage hides the complication that (may) be in the method from the caller. Encapsulation is all about hiding complication.

In the end, does it feel right? This may take experience but if it feels right, go for it.

*i am a starter , trying to learn the GOF patterns.
i am using vb.net , understand c#. still wan't a job in holland as starter in vb.net Wink | ;)

.
i am a person who doesn't want to have full blown solutions , i want to learn by coding , what is happening deep inside the logic.

*i am trying to serialize my tree , filled with nodes that work like groups(with nodes) / transforms(leaf) / 3d-meshes(boxes/ball/other primitives) in a world node.
yes i am trying to share my servers '3d world' with my clients.

*but when i try to serialize my tree to xml , i end up with errors like :
-my leaf objects cannot have children.
-xml serializer cannot recognize what kind of object a child is.

*i am now trying to build my personal serializer , that breaks up my tree into a array of objects , and then seperately serializes each object.

*in the future i want to grasp the idea of sending the whole world state and the delta-state (difference in worlds , inbetween two times).

*did anybody found some examples. or know some ideas how to help me ? OMG | :OMG:

Jarno Burger
Video Jockey

Hi,
trying to learn the GOF patterns
Good thing to learn about, I finally bought the book a few months ago.

trying to serialize my tree , filled with nodes
I had a look into serializing a tree and I got as far as serializing the objects contained within the nodes and leaves but not the actual 'tree' information such as child/parent/leaf used to construct the tree. Which meant I could not reconstruct it. When running my (C++) program I used a Windows tree control CTreeViewCtrl to visualize the data and a third party tree container to actually hold and manipulate the data and linked the two together.
I serialized the various classes that made up the objects held in the tree container using the Boost library but was not serializing the container structure. The question then arose as to should I serialize the container - which would then make the program dependant upon that container. If I did, how?
This is where I left it a few months ago.

my leaf objects cannot have children.
Leaves cannot have children, thats correct

-xml serializer cannot recognize what kind of object a child is.
I used the Boost library which got round this by allowing simple additions to class code to allow each object, when serialized, to store what type of object it was - and what it inherited from. Reconstructing then created the correct objects.

I would like to get some ideas on the best way to handle dealing with data in an object oriented system. Consider:

User
=======
UserId
UserTypeId
FirstName
LastName
OrganizationId

UserType
===========
UserTypeId
Name

Organization
============
OrganizationId
Name
District
YearFounded

How would you model these database tables with your objects?

For simple lookup table data, would User have a property for just UserTypeId or would it have a property of UserType(which includes both Id and Name)?

For more complex data, would User have a property for just OrganizationId or would it have a property of Organization?

If you go the route of having only an Id as property, how do you manage the display of property data, for instance, when displaying the User in the UI, you still need to display the UserType.Name value, and not just the Id. Would you load and cache a collection of UserType objects and use this to lookup the UserType.Name value when needed?

Would it make sense to expose a readonly property User.UserTypeName for convenience that provides the name value? I say readonly since you can edit the Id value, but not the actual UserType name when saving a user.

The object graph can grow large with several interactions... what rules do you use to draw the line as to where an object instance and its related graph stop?

Thanks for any opinions. Assume the objects must be WCF friendly for use as data contracts.

Firstly, I see no mention in your post of considering the "responsibility" of an object as part of the design process. This indicates your view of Object Oriented Design is far different than mine.

If you are asking how to mimic database table structure in your coded structures then that is an entirely different question. The most common method of doing that today is to use one of the many Object Relational Mapping tools to generate the code for you. Of course there are almost always problems associated with them but hey, if all you had to do was click a button then any monkey could do it and we would all be out of work.

Many people here on CP seem quite fond of using the new LINQ features in the .NET platform. Don't know if you can use that but if so I recommend looking into it.