|
Ok, I've gotten it to move horizontally, vertically and diagonally fine so i've added boundaries so that it can't move past the screen limits. However when i added that it just shakes back and forth. From what i understand it first increases the x co-ordinates, moving the window to the right. Then the if statement checks if it has gone past the left of the screen and if it has it will reverse the direction the window moves. The second if statement checks that x co-ordinates including the width of the window doesn't past the width of the screen. Is this all correct?
private void timer4_Tick (object sender, EventArgs e)
{
this.Left += WindowVx;
if (this.Left < 0) {
WindowVx = -WindowVx;
}
if (this.Left + this.Width > ClientSize.Width) {
WindowVx = -WindowVx;
}
this.Refresh ();
}
|
|
|
|
|
So what you want it to do is move all the way right, then when it reaches the edge, turn round and move the other way?
To do that isn't difficult - when you reach the screen edge, change the sign on the value you are adding! Then, when you reach the other edge, change it back again.
Left += deltaX;
if (Left < 0 || (Left + Width) > ClientSize.Width)
{
deltaX = -deltaX;
}You don't need to specify this all the time - you only need it when you have a local variable of the same name as your class level one and you want to access the class level variable.
You also don't need to refresh anything - when you update Left and Top they will refresh for you.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Hm... for some reason the window just moves back and forth kind of like it's vibrating. I'm not really sure what's causing it as the code without the if statement works fine.
This is the code right now:
this.Left += WindowVx;
if (Left < 0 || (Left + this.Width) > ClientSize.Width){
WindowVx = -WindowVx;
}
|
|
|
|
|
Check your "ClientSize" object and see what values it has - at a guess the Width is zero.
You know how to use the debugger, yes?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I checked and the width is 282 i think. And by debugger you mean like the play button on xamarin studio? That's what i've been using to test my program.
Also just in case i'll post the rest of my form information.
this.AutoScaleDimensions = new System.Drawing.SizeF(8F, 16F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.ClientSize = new System.Drawing.Size(282, 253);
this.ControlBox = false;
this.Controls.Add(this.webBrowser1);
this.KeyPreview = true;
this.MaximizeBox = false;
this.MinimizeBox = false;
this.Name = "Form1";
this.ShowIcon = false;
this.ShowInTaskbar = false;
this.Text = "test";
this.TopMost = true;
this.ResumeLayout(false);
|
|
|
|
|
OK: so you can't affect the Left and Top of your current window - because the ClientSize of the current window is going to be at best the same as the width of the window!
So, if you are trying to move something within the current window, use its properties: Left, Width, and Top, and the Window Client Area.
Your original code shows you being inside the form, so this refers to the whole form, not anything within it. If you are trying to move the form, then you need to get the information on sizing from whatever it is displayed on - probably the desktop (or android equivalent, if that's what you are using).
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
When you say move the form do you mean the things inside the window? I'm trying to move the entire window and by information on sizing do you mean my screen resolution? If i use Left, Width, and Top, and the Window Client Area to move the thing inside the window, do i need something else to move the window itself?
Edit: Oh i just looked it up and form is the window itself.
|
|
|
|
|
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[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
