|
Too easy. Look at the DateTime and TimeSpan classes. Use something like
DateTime start = new DateTime(... ... ...);
DateTime finish = new DateTime(... ... ...);
TimeSpan worked = finish - start;
then pull worked apart as you need.
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Hi Perter_in_2780,
Thanks for Your Reply. But Still I am getting Incorrect Result. I have only Time. When I convert the Out Time in datetime Then Both the Time that is employees out time and shift out time has default date as todays date and if the Emd Time Of Employee is 12:00 AM and Shift Out Time ois 6:00 PM Then Iam Getting the Result is 17.00 in TimeSpan.
Which I dont want. I want Result as 6:00. Iam unable to calculate time difference in case when time is from PM to AM.
Thanks & Regards
Sanket Patil
.
|
|
|
|
|
You need to include at least part of the date in start and end DateTime's. The dates can be "made up", like this:
DateTime start = new DateTime(2000, 1, 1, 18, 0, 0);
DateTime finish = new DateTime(2000, 1, 2, 9, 0, 0);
TimeSpan worked = finish - start;
... That should come out at 15 hours.
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Check this[^] out.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
Hi Abhinav s,
Thanks for your reply But I am Not Getting The Solution if its night shift.
Thanks And Regards
Sanket Patil
.
|
|
|
|
|
For the night shift split the calc in 2 start to 24:00, 00:00 to finish. Decide which calc to use based on the start time or if the end time is less than the start time. Os as others have suggested add the date to the start/end variables.
Bloody hell this is simple stuff, try thinking.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
This is exactly why you store start and end date and not just time.
If you stored:
start date = 2010-09-12 20:00:00
end date = 2010-09-13 07:00:00
then you would have no problem.
Go back and fix your model/database before you continue with incorrect data storage.
|
|
|
|
|
Hi,
there are only two cases that could work well:
1.
you have date AND time information, not just time. Then a TimeSpan calculated as the difference of two DateTime values is perfect.
2.
you only have time information, but you also know the context enforces something. In your case it would be: the time worked is anywhere between 0 and 24 hours. So, calculate the difference in any way you see fit (even with TimeSpan=DateTime-DateTime where both DateTimes have the same or no date), then enforce your boundary conditions: if the TimeSpan is less than zero, add 24 hours.
|
|
|
|
|
Hello coders,
I am new so please go easy
OK, my application has a licensed state that is either 1)Valid 2)Trial 3)Invalid or 4)Expired
I will have an object (class) called license to handel this, along with the main form of my app.
Now I have a few questions.
1)How should I represent the available options?
Should I use enum licinse_state { trial, full etc
or simply set the property in the relevent function to a string
e.g
if(license is a full one)
string license_state = "FULL"
return license_state
2)What functions should go in the license class, what in the main form?
3) If I have a form to get the serial number, should this be called from my main form, then the serial number passed into my license class, or should I invoke the license class from my main form and then call the serial dialog from the license class?
Bit confused about what to put where, and what to call from what!
Thank you!
|
|
|
|
|
Hi
1.
yes, a limited number of possible values is exactly what enum is aiming at.
BTW: don't use strings for anything but text; if you are performing logic operations, use bools (not "true" and "false" strings); if you are counting, use integers (not "one", "two", "three" strings).
2.
it is good practice to separate actual things from user interaction things; the former are "business objects", the latter constitutes your GUI ("Graphical User Interface"). The properties, the logical expiration, the encryption, etc. that are associated with a license, all fit in a License class. Whatever you decide (now or later) to either look at a license, or to enter/edit license information, is completely separate from the license itself. You may end up having several products, all dealing with licenses based on one and the same License, but having different means to view and edit a License.
So design a License class, and a LicenseEntryForm class. The latter will use an instance of the former to store and operate on the license data.
3.
No, your License class should not hold any GUI stuff (see #2), it does not know the first thing about the user. For all it knows, the user may speak French or Vietnamese.
It is a bit confusing at first, you will get used to it.
You may have to read up on properties (don't make data members public!), possibly also on events and delegates.
|
|
|
|
|
stephen.darling wrote: 1)How should I represent the available options?
IMO, enums are an indicator that there is an underlying problem with you class structure (others will disagree with me on this point [edit - see Luc Pattyn's response above]).
For example:
- Expired - can it be determined from an expiry date? If so set an expiry date property and have a read-only
IsExpired property - Trial - create a boolean
IsTrial property - Invalid - Why would you issue an invalid license? If you really do need this, you could have an
IsValid property instead, preferably this would be read-only and determined from the object state (e.g. is expired and is trial, or some other combination of "rules".
Doing this would allow you to have an expired trial license and expired normal license. Another way to factor out the enum is to create a subclass per state, but I don't think this suits your problem well.
stephen.darling wrote: 2)What functions should go in the license class, what in the main form
Anything relating to the function of the license should go in the License class, e.g. if the license can be extended (i.e. it's expiry date moved later), this should handled in the License class. The form should only deal with showing the information to the user and calling the License class's methods. In the example I gave, you might have a button to extend the license by a year. In this case, the button event handler is in the form, but it would call the code on the License class to do the actual update (remember that anything long-lived, such as database or service calls should be done on another thread). The separates the concerns of what the application does out from how it interacts with the user. To start with this will seem like a pain, but as the application grows your life will be made easier.
stephen.darling wrote: If I have a form to get the serial number, should this be called from my main form, then the serial number passed into my license class, or should I invoke the license class from my main form and then call the serial dialog from the license class?
Ideally, the License class should get the serial number, called by the form. You need to clarify what the form to get the serial number actually adds before I can help with this more fully.[Edit] Although I might look like I contradict Luc on this matter, I agree that the GUI should not do license stuff, and the license model should not do GUI stuff! I think it is probably the responsibility of the License class to get its serial, but this is dependant upon the work the UI needs to do to get the serial number.
Like Luc said, it is confusing, but with experience you'll get the hang of it, at least you spotted this problem beforehand, unlike far too many others ...
ragnaroknrol The Internet is For Porn[^]
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.
|
|
|
|
|
To follow on from them...
Full and Trial could be determined from the absence or presence of an expiration date (or an expiration date of MaxValue) (perhaps use MinValue to indicate invalid ::shrug:: ).
And, as they said, how you represent it inside the license class will differ from how it's presented to the user.
|
|
|
|
|
Thank you very much for all the excellent advice!
Could I just clarify the following.
I have my main form, the main app that runs first.
2) When the form loads, It needs to check for the license
3) If the user simply leavs the serial number field blank, it runs in a trial mode.
So, I have the following
1)Main form
2)License dialog form
3)License class
So, do I...
Run showdialog() in the mainform()
then load the serial from that using dialog.result() == OK (etc)
then create a license using:
license lic = new license();
then check it...
lic.checklicnese(string from above dialog)
Have I got this right?
Thank you again
Steve
|
|
|
|
|
Maybe have it start out in trial mode and have a menu option to allow the user to register a licence. Clicking the menu item would cause the ShowDialog. If the dialog is canceled, you would continue in trial mode.
0) If the expiration is MaxValue: full functionality.
1) If the expiration is in the future: trial functionality.
2) Otherwise: no functionality (other than register and exit).
|
|
|
|
|
Hi, I'm looking for the most logical way of taking screenshots of multiple clients(say 20-30 PCs) from a server simultaneously. What I plan to do is below, your valuable comments are very welcomed
1- server sends request to clients simultaneously
2- Clients take the screenshots, serialize and sends to server
3- server shows them all on a form with reduced size (if better,clients can take reduced screenshots in the beginning)
Thanks!
|
|
|
|
|
And your problem is?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
OriginalGriff wrote: And your problem is?
My problem is; is it good to serialize or is there a better way. Is taking all the screenshots simultaneously good idea for the performance side? Is the way I am taking right?
|
|
|
|
|
teknolog123 wrote: is it good to serialize or is there a better way
Probably - it has the advantage of relative simplicity. However, you might find that either saving it to a database (which would depend on the databases you have available but they all support it), or to a file on the server is as simple (Image.Save(myPathName) is pretty simple...) I would probably go with the database option, but then I always have databases kicking about and the DB engine gets to handle the multi-user aspect of things - which it is pretty damn good at!
teknolog123 wrote: Is taking all the screenshots simultaneously good idea for the performance side
Why would that have any effect on performance? Each PC would have to take it's own screen shot, so there is no performance hit anywhere I can see.
teknolog123 wrote: Is the way I am taking right?
That depends on what you are trying to achieve!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
teknolog123 wrote: is it good to serialize or is there a better way.
To achieve what exactly? If you want this log on the server, then it might be best to just dump the screenshot on the client and to zip them and to pick these packages up at midnight.
Blasting each screenshot over the network as soon as it's taken would definitely add to the networkload. Depends on the quality and the size of your screenshot. Would you need to save it in full-color, or would a grayscaled image suffice?
teknolog123 wrote: Is taking all the screenshots simultaneously good idea for the performance side?
The overall performance on the client, the server, or the networkload? I'd suggest a round-robin, where the server 'requests' a screenshot from a client, then moves on to the next one. When done, rinse and repeat.
I are Troll 
|
|
|
|
|
Taking a screenshot is a local matter, it is the client that does the work.
Sending the result to the server is also the client's job.
teknolog123 wrote: server shows them all on a form
You mean the server has a manned display? OK, no problem.
If the only purpose of the screenshots is to show them all at once at reduced resolution, then there is no need to transmit and/or store them at full size. If so, the client action should be:
- create a Bitmap containing the screen content
- create a new and smaller Bitmap from the earlier one
- send it to the server (using a shared folder, a database, whatever, on the server.
How often do you want this? is this a classroom supervisory system? taking movies of all client activity?
there may be capacity concerns, bandwidth concerns, privacy concerns.
|
|
|
|
|
Luc Pattyn wrote: How often do you want this? is this a classroom supervisory system? taking movies of all client activity?
This is for a classroom. The screenshot will only be taken by the admin not by specific intervals. It won't be saved to anyware, screen will be observed just for that moment.
|
|
|
|
|
I see no technical problems.
I recommend you let the clients take the first initiative, i.e. each client PC connects to the server and requests participation in the whole thing; that avoids you have to maintain a list of clients (beyond the class session), and gives you an opt-in situation, something most law systems cannot object to.
|
|
|
|
|
|
you're welcome.
|
|
|
|
|
I have a panel with transparent background, that I want to paint on multiple times. It paints alright the first time, but each time after that the drawing gets thicker. This problem is only with transparent backgrounds, drawing anything on it multiple times will make a drawing thicker on each painting event.
Any ideas how to overcome this problem?
modified on Sunday, September 12, 2010 8:10 AM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
