|
Thank you. I will do that.
|
|
|
|
|
hi, this is good information regarding the database,
thank you also i will don that,
|
|
|
|
|
hello friends ,
i have a problem my sight working good in IE6 but its not working in IE7.in ie7 design is not right. specilly date time picker and fileupload control.some controls are on the controls..what may be the problem...?thnx in advance
|
|
|
|
|
hey, i am trying to make a new file extension, i have looked on the internet and cant find and thing. this is what I'm trying to do. when the user clicks on the .hnh it executes the exe in side of it, along side of the exe is a text file and i am aiming for the exe to write records in the text file inside of the .hnh, if someone could help or point me in the right direction that would be great.
also i was not sure where to post this if there is a better place please tell me, thanks
If at first you don't succeed
Redefine success
J.Hardy
|
|
|
|
|
Huh? You want to nest a file inside a file?
Why would you want to hide an exe inside another file type, unless you want a user to execute it without knowing it's executable? I can't imagine any reason for this that isn't a crime. Why not store the executable as an exe file, and its data file as txt? You wouldn't be thinking of writing something malicious would you? If so, this would be a really good time to go somewhere else. If not, please clarify.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
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. 
"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. 
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. 
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
