|
Backup a second...
When you are a form, you have four properties you are interested in: Width and Height - which tell you how big the whole form is; then Top and Left - which tell you where you are relative to the container the form is displayed within. For Windows, that's the Desktop - so Top and Left of zero is the top left hand corner of your monitor.
The Client Area of a form is the bit of the form that isn't the title bar and the form border and it measured relative to the form top left corner - so the Client Area will normally be smaller than the Width and Height, and never, ever bigger.
So trying to move the form doesn't involve the form's client area for "reaching an edge" - it involves whatever the form is contained within: normally the Desktop.
See if you have a Screen object you can access the Width and Height from and try those.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Oh i think the problem is that sometimes the window is created partially outside the screen resolution and for some reason the if statements make the window start vibrating because it's constantly changing directions. So to fix the problem i need to make sure that the window isn't created outside of the screen.
I changed a few things and it seemed to fix a majority of the problems:
WindowX = (random.Next(0, width - Width));
WindowY = (random.Next(0, height - Height));
this.Left += WindowVx;
if (Left < 0 || (Left + this.Width) > width){
WindowVx = -WindowVx;
}
this.Top += WindowVy;
if (Top < 0 || (Top + this.Height) > height) {
WindowVy = -WindowVy;
}
However sometimes the window is still created a bit past the bounds for some reason, but I'll work on it tomorrow, for now i need to sleep. Thank you for the help so far though!
Oh, and for screen object, do you mean this?:
private int width = Screen.PrimaryScreen.WorkingArea.Width;
private int height = Screen.PrimaryScreen.WorkingArea.Height;
I changed it to this:
private int width = Screen.PrimaryScreen.Bounds.Width;
private int height = Screen.PrimaryScreen.Bounds.Height;
That way it'll go over my task bar.
|
|
|
|
|
Sleep well!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
That was an excellent thread ! Very nice OG
|
|
|
|
|
For i = 1 To ListView1.Items.Count
' Dim Cm1 As New SqlCommand
'Dim dr1 As New SqlDataReader
'Dim da1 As New SqlDataAdapter
Try
Dim Cm1 As New SqlCommand
' Dim dr1 As New SqlDataReader
Cm1.Connection = con
Cm1.CommandType = CommandType.StoredProcedure
Cm1.CommandText = "sp_ins_tbl_GE_Det"
Cm1.Parameters.AddWithValue("@GE_HDR_TRAN_ID", TRN_ID)
Cm1.Parameters.AddWithValue("@val_GE_HDR_ID", Transaction_No_hdr_ID)
If con.State = ConnectionState.Closed Then
con.Open()
End If
If rbPurchase.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "PURCH")
ElseIf rbSales.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "SALES")
ElseIf RBSTOCKTRANSFEROUT.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "STKTROUT")
ElseIf rbInterDept.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "INTRDEPT")
ElseIf rbCONTRACTORITEM.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "CONTITEM")
ElseIf rbSalesReturn.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "SALESRET")
ElseIf rbPurchaseReturn.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "PURCHRET")
ElseIf rbGatePass.Checked = True Then
Cm1.Parameters.AddWithValue("@val_Type_Of_Vehicle", "GATEPASS")
If (rbSales.Checked = True Or RBSTOCKTRANSFEROUT.Checked = True Or rbSalesReturn.Checked = True) Then
' ' Cm1.Parameters.AddWithValue("@val_Customer_Code", lvi.SubItems.Add(CStr(dr("Customer_Code"))))
Cm1.Parameters.AddWithValue("@val_Customer_Code", lvi.SubItems.Add(CStr(dr("Customer_Code"))))
Else
Cm1.Parameters.AddWithValue("@val_Customer_Code", "")
End If
If con.State = ConnectionState.Closed Then
con.Open()
End If
dr = Cm1.ExecuteReader()
' Cm1.ExecuteNonQuery()
Cm1.Dispose()
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
Next
End If
|
|
|
|
|
You already have this posted as a QA question: please do not post the same thing in multiple places, it duplicates works and annoys people.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
And before I forget, why would you post VB in a C# forum?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Why we write unnecessary declarations of methods. We must Implement these methods.
So, why we write extra line of code in declaring method.
What is benefit of it?
Can anyone make me understand its benefit in more detail?
Thanks
|
|
|
|
|
If a class implements an interface, you know it contains specific items, functions or methods. You could of course also use abstract class to do it too.
|
|
|
|
|
They aren't "unneccessary" methods, they define the methods that must be implemented in order to use the Interface.
If you think of an Interface as a contract rather than a class, the properties and methods defined by the Interface are conditions attached to the contract that must be adhered to or the contract is broken.
One of the best examples is the IEnumerable interface which "allows" you to use your class in a foreach statement. It has the "condition" in its "contract" that your class must implement the GetEnumerator method, because that is what the foreach loop calls in order to iterate your class. If you don't implement it, the compiler will complain because the contract is "broken" and any foreach loop which tried to reference your class would fail.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: the IEnumerable interface which "allows" you to use your class in a foreach statement ... If you don't implement it, the compiler will complain
Not entirely true. 
The compiler actually uses a form of duck-typing, so that any type that has a GetEnumerator method which returns a type that has a suitable MoveNext method and a Current property can be used in a foreach loop.
It's a throwback to the pre-generics days of .NET 1.x, and was mainly intended to avoid the boxing overhead involved with enumerating collections of value types.
public struct DuckEnumerator
{
public bool MoveNext()
{
return true;
}
public string Current
{
get { return "Quack!"; }
}
}
public class Duck
{
public DuckEnumerator GetEnumerator()
{
return new DuckEnumerator();
}
}
int count = 0;
var donald = new Duck();
foreach (string value in donald)
{
Console.WriteLine(value);
if (++count > 42) break;
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
It's a "lies-to-children" example: Lies-To-Children - Discworld & Terry Pratchett Wiki[^]
The truth about foreach is more complicated than is needed when you are getting started with the concept of interfaces, so I didn't want to add to the confusion.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I think the choice of the word “interface” was a poor one in the first place since it conjures up one kind image (how to “communicate” with something), when I like to think of it more as a statement of code that is shared.
For example, there are different kinds of "horse races": maiden; maiden special weight; maiden claiming; claiming; optional claiming; allowance; stakes; handicap; etc.
Then there are “past performances”, which are races that have been run.
Programming against “races to be run” and “past performances” seems different enough, but they also have a lot in common when it comes to “consuming” them (as in a report), so we define an interface (e.g. IRace) so that any code that “uses” IRace “knows” that there will be available: a race date; track code; race#; horse name; etc.).
It doesn’t matter if the code in question is running against “today’s race” or a “past performance”, the code is content just to know that the thing has IRace behavior.
“Interfaces” supposedly are an alternative to “multiple inheritance” which C# doesn’t allow; but that’s another story. Also, deciding between refection, dynamics, “interface”, “inheritance”, “generics”, etc. or some combination thereof makes it all a bit less than simple, when it comes to writing "reusable / shared code".
|
|
|
|
|
So... they lead to a race condition.
This space for rent
|
|
|
|
|
Yes; but I like to tell people it's only a hobby.
|
|
|
|
|
Member 9730878 wrote: What is benefit of it?
A short practical example; you'll see below code in some tutorials on the internet;
using (SqlConnection con = new SqlConnection("famousstringhere"))
using (SqlCommand cmd = con.CreateCommand())
{
..
}All those db-providers implement the same interface. In below code it is easier to swap the concrete class you're using;
using (IDbConnection con = new SqlConnection("famousstringhere"))
using (IDbCommand cmd = con.CreateCommand())
{
..
}It also means I can program against an interface that's already known, without having a specific class. Or have one injected by a framework. Or make that user-configurable 
The difference in learning the benefit is like being bound to a single database, or have the user configure the database of their choice in a file.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Unfortunately, not the best example.
You could also swap out the concrete classes for their abstract base types (in System.Data.Common), which gives you many of the same benefits. The abstract base classes also include the task-based async methods, which are missing from the interfaces.
using (DbConnection con = new SqlConnection("..."))
using (DbCommand cmd = con.CreateCommand())
{
cmd.CommandText = "SELECT 42 As TheAnswer";
await con.OpenAsync();
int result = (int)(await cmd.ExecuteScalarAsync());
}
Also, given the huge difference in the syntax used to access different databases / providers, you're unlikely to be able to reuse your database code anyway.
If your data access code is scattered around your application, even if you've used the interfaces or base classes, allowing the user to switch databases by editing a file would potentially be a nightmare. They would need to be able to change the CommandText and CommandType of every query, and define a map from your internal parameter names to the query parameters - possibly including duplicate mappings if the provider doesn't support named parameters.
If it's a requirement, it would probably be simpler to create a separate data access assembly for each supported provider, and use some form of DI to let the user swap providers as required. At which point, you do need an interface for the data access classes.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Unfortunately, not the best example.
Best example I could come up with based on practical use. It is a pattern that is easily recognized because many people used it in one form or another, and where you have an easy to explain benefit that is easily achieved.
Richard Deeming wrote: Also, given the huge difference in the syntax used to access different databases / providers, you're unlikely to be able to reuse your database code anyway.
Yes. Next to their specialized dialects most databases also adhere to some form of a standard, with mine being SQL92.
I am not saying that you can make a complex application database-independant by swapping out some type-declarations, I'm claiming it is one of the things you can achieve if you are aware of their existence.
Another simple example would be to program against an interface and couple it with a class lateron. Something like "ISomeFancyEngine engine = new ISomeFancyEngine()". Not the best way to highlight anything an interface can do, but an example that shows a direct benefit one might have.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Actually, I am working on a Windows application and I want to add inkPicture to capture users signatures to the database. The signature column data type is varbinary. The problem is that the record is added to the database but it shows it as null only.
This is what I have done so far:
string con = "Data Source=SAIUNIFLOW;Initial Catalog=documentfollowup;Integrated Security=True";
byte[] saveInk = (byte[])axInkPicture1.Ink.Save(InkPersistenceFormat.IPF_GIF, InkPersistenceCompressionMode.IPCM_Default);
cmdDatabase = new SqlCommand();
cmdDatabase.Connection = conDatabase;
cmdDatabase.CommandText= "insert into manage (Signature)" + "values('" + axInkPicture1 + "'); ";
cmdDatabase.Parameters.AddWithValue("@Signature", saveInk);
Iam using tablet for getting the signatures but when I click the insert button, I receive that error:
Cannot insert the null value into column Signature, table doesn't allow nulls.
Hopefully to help me to solve this error.
|
|
|
|
|
|
|
Thank you for your reply. The same error. It is showing saveInk as null
|
|
|
|
|
I received the following error in
cmdDatabase.Parameters.AddWithValue("@Signature", saveInk);
which is
object reference is not set to the instance of object
|
|
|
|
|
So debug your code and find out which object is null.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Where did you assign a value to saveInk? How does your current code look?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
