|
I think you need to do some very basic research. Entering data into a database is a very common task that is covered in numerous resources, as is using a datagrid.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
In your case if you set the data source of the datagrid to be a select query with the 4 fields needed by the datagrid selected, you will have to do some work to make it write back to the database table with the modified values together with the values from the two labels to all 6 fields. The "lazy" binding will not work automatically for you.
There are easy solutions to this problem, though. The binding of datagrid to a table (so that you can update the table) works well if you have all the fields needed for the table to be updated selected in the datagrid. You always have the freedom to use in-memory table to achieve this. Create a DataTable with the four fields that are needed for the datagrid and bind it to the datagrid. (If you need to modify existing records you need to populate this DataTable first.) In the "Save" button handler, use code to update the real table by the data in the DataTable AND the values in the two labels.
I am sorry I can't offer you a code sample for this but I assure you this works. I have done this in my projects, and it is not that complicated.
Good luck and happy programming!
|
|
|
|
|
I'm currently dabbling into digital signage and I'm having troubles with a monitor turning off on me. My question is this : is there a way in C# code that I can tell if a monitor is currently on or off? I'm writing an alert system for me since I cannot correct the monitor's issue at this time.
I've tried looking into system.manager, system.environment, and systeminformation... but was unable to find anything which was able to tell me the monitor's current state.
Specs:
Monitor : Samsung TV
PC: Windows XP PRO 32-bit
|
|
|
|
|
CP has every answer (well, almost). Try here[^].
It does not give the state, but you can play around with the code to see if it helps you.
It uses some Com Interop though.
There are only 10 types of people in this world — those who understand binary, and those who don't. |
modified on Tuesday, January 12, 2010 10:08 PM
|
|
|
|
|
So you want to write an application that tells you when your monitor is off?
What's wrong with just looking at it?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
In Visual Studio 2008 when writing a console application for C# in Debug you were able to click 'start without debugging' to view the results of your program then 'press any key to continue'.
Visual Studio 2010 (beta 2) does not offer that option. How do you overcome this?
|
|
|
|
|
Well, if you're concerned that your console window will close too quickly by running it with debugging (i.e. without prompting 'press any key to continue'). You can simply add a call to Console.Readline(); at the end of your Main function. This will keep your console window open until you press a key.
for example:
static void Main(string[] args)
{
Console.Write("press any key to continue");
Console.ReadLine();
}
Hope that Helps!
|
|
|
|
|
Thank you Elegantly simple.
|
|
|
|
|
I think you mean ReadKey() - yes?
|
|
|
|
|
Either one will work. The point is to have the application wait for input before continuing.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I have a single-form application which I would like to call this.Close() when it ceases to be the active window of the OS. How do I do this?
|
|
|
|
|
Use the form's Deactivate event possibly
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
Add a handler for the Form.Deactivate event. Call Close() in the body of the event handler.
|
|
|
|
|
|
Do you want to close the app, or hide the window?
Either way, handle the LostFocus event for the form, and do what you want there. Calling Close() in that handler will close the application.
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
hi all,
i just want create an email account through MAPI or whatever in exchange server . how it is possible?
|
|
|
|
|
I have made a custom date control using button and text box. Every thing works fine. What i need to know is when the control is placed on a form of smaller size and we click on the button in runtime the control goes behind. but in case of windows datepicker in such situtation the control comes ahead of form. How can we achieve this.
|
|
|
|
|
I do not know entierly sure what you mean. Maybe a screenshot would help. I am only guesing.
Such as ComboBox and DateTimePicker. Items shoud be painted on Primary (Non-Client area or Desktop) Display. If you use normaly GDI and draw on client size, and the form is not big enough, then popup wouldn't be painted entirely or a other controls could come on top of other
|
|
|
|
|
amitsol wrote: but in case of windows datepicker in such situtation the control comes ahead of form. How can we achieve this.
Not the entire control - at least not if it's partially hidden by a textbox. You're referring to that hovering thing below the date-line? I think that's a window, created in a similar fashion as the tooltip-window.
You might be able to reproduce this by using a ComboBox . It also flaps out a small window
I are Troll
|
|
|
|
|
Hello
I am working on a system for C #. NET
Problem
The date in the screen 12/01/2010
But when I store the date in the database sqlServer storage is as follows
22.06.1905
What is the problem
How can I solve this problem
thanks
Thaer
|
|
|
|
|
Without seeing your code, it is difficult to tell.
Best guess is that you are storing the date as a string, the format of which is local to your region and / or culture. SQL databases use an internal format of "YYYY-MM-DD" and are culture invariant.
Do not keep your date as a string - store it in a DateTime and pass that to the SQL directly. Convert it to a display string as late as possible, and convert from a string as soon as possible. Not only is it more efficient in terms of space, but you can easitly perform operations such as comparisons, additions, etc. which you cannot with a string.
All those who believe in psycho kinesis, raise my hand.
|
|
|
|
|
Hi,
your question isn't particularly clear, however this[^] might be useful.
|
|
|
|
|
I'm not exactly sure what you mean. Do you want to store the Date in a specific manner? If that's the case then check if SQL supports your date format. If not make a function that creates the date in the specified format.
Or you could create a DateToString() method or the other way around.
Any way you could use: dt = DateTime.Parse() and then
check the month,year and day.
Again I'm not sure what you want.
|
|
|
|
|
Hi fellow developers.
I come with 2 questions today around the area of serialization. I would normally try these things out myself, but I am away from my development machine today and I was wondering you if you could provide some assistance.
If you added a new property to an existing class that your web service serializes and returns to clients, would it break for existing clients?
If you changed the data type of an existing property of an existing class that your web service serialises and sends to clients, would it break for existing clients?
Many thanks,
TF
|
|
|
|
|
Hi,
Adding a new property would normally not break existing clients. Since this is a web service and the client might consume the soap-formatted XML responses in any way there is no guarantee. For example, a client *could* have been implemented in such a way that it assumes the fifth childnode of some element to be "dateOfBirth" and parse it's text as a date, and this would obviously fail if the message format changed so that dob no longer was the fifth childnode. However, part of the point of using XML is of course to enable to use the node names instead, so picking nodes by index is bad practice.
Changing the type of an existing property is much more likely to break existing clients, though it need not always happen. Again things are fuzzy since a client could be implemented in any of a number of technologies, and with any number of tools. Changing from "int" to "byte" might be safe, but might not. I don't know the type definitions in W3C's standards, but generally the only safe changes you can make (that cannot break properly implemented clients) would be thos that result in the property still mapping to the same type in the SOAP message.
You might be thinking of only a subset of the possible clients though, such as .NET clients generated with Visual Studio. Even then there are a few varieties; at least two: WCF clients configured to connect to a web service endpoint, and "pure" web service clients. Adding a property to a class won't affect such clients. Changing the type will also be fine as long as the values actually returned from the service are valid for the old type. Changing from Int32 to byte for example breaks nothing (but also doesn't achieve much), while changing from int to double works (but is pointless) only so long as the values returned fit in an int.
|
|
|
|