|
Allright, this is probably a stupid way to do it, but it should work.
First, move the project to the location where you want it to be
(just move the whole folder).
Then do this in Visual Basic C# Express Edition:
On the File menu, select New -> Project from existing code...
Then find the folder that you just moved, and type the path in the
"Where are the files?" textbox, and check the "Include subfolders" checkbox.
The project will then be created at the new location.
Note: I haven't tried this, but it should work.
Virtual1ty
"Any fool can learn from his own mistakes, but a wise man learns from mistakes of others"
|
|
|
|
|
Alright, i'll give it a try.
|
|
|
|
|
Easiest way to do this:
Open your solution. While the solution is open, delete the .sln file in Explorer.
Build your project by going to the Build menu. Before it will build, it will prompt you to save the sln file. Save it to the location of your choosing.
Note, this only works on VS2005. VS2003 will probably barf.
The early bird who catches the worm works for someone who comes in late and owns the worm farm. -- Travis McGee
|
|
|
|
|
How do I set the menu strip to a picture and when I right click it, it will open the menu up?
 <-- Like an image like that and you right click it, it opens a menu.
|
|
|
|
|
Attach a context menu to the click event of your image
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
Thanks,
Can't figure out what to type, is it:
System.Windows.Forms.ContextMenuStrip; ?
|
|
|
|
|
Yes sir. You can do a drag and drop from the designer toolbox, or you can do it like so:
{
System.Windows.Forms.ContextMenuStrip cmuMenu = new ContextMenuStrip();
}
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
|
Yup, you bet. Hope that solution is the one you are looking for!
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
And please try to use more descriptive titles, i've seen about 4 topics with the title 'How do i...' in the last few days.
My current favourite word is: Waffle
Cheese is still good though.
|
|
|
|
|
Can someone direct me regarding coding standards for C#?
I am new to C# and am currentyl moving to C# from VB .NET
Most of my previous programming experience has been within procedural programming languages so OOP is fairly new to me.
C# with curly brackets is entirely new to me.
To give you some idea of how I code I have included a simple code snippet below.
Comments suggestions etc gratefully received(please be gentle or I might return to VB .NET )
<code>
class Prime
{
double testNum, testLimit;
public bool isPrime(double numIn)
{
testLimit = numIn;
testNum = 3;
if (testLimit % 2 == 0)
return false;
while (testLimit > testNum)
{
if (numIn % testNum == 0)
return false;
testLimit = numIn / testNum;
testNum += 2;
}
return true;
}
}
You always pass failure on the way to success.
|
|
|
|
|
GuyThiebaut wrote: Comments suggestions etc gratefully received(please be gentle or I might return to VB .NET)
I think everyone will be nice, NO ONE wants you to return to VB.NET 
Everything looks good to me, I have one one suggestion.
GuyThiebaut wrote: if (testLimit % 2 == 0)
Logically, it doesn't matter. I always find it best though to put the constant on the left hand side of a comparision operator. Example:
<code>if (0 == testLimit % 2)</code>
or
<code>
if(string.empty != strMyString)
{
MessageBox.Show("This string contains stuff!");
}
</code>
Like I said, it really doesn't make any difference, but it makes your code a lot more readable, and if someone else happens to be working inside your code, it will give them a better understanding of what is going on. Just my $0.02
Good luck in your quest to learn C#, I think you will find it very similar.
I get all the news I need from the weather report - Paul Simon (from "The Only Living Boy in New York")
|
|
|
|
|
Thanks Justin,
Will follow your suggestion with regards to the positioning of constants within comparisons.
I'm already beginning to like the simplicity and lack of wordiness of C#.
You always pass failure on the way to success.
|
|
|
|
|
Justin Perez wrote: I always find it best though to put the constant on the left hand side of a comparision operator.
That's a left over from C/C++, where the boolean type is numeric. Putting the constant first keeps you from accidentally using the assignment operator instead of the equality operator. In C# the boolean type is not numeric, so there is no need to do this.
Also, putting the constant first is only more readable if you are very used to reading it exactly that way. The logic way to write it is to not swap them around so that the constant is first.
---
single minded; short sighted; long gone;
|
|
|
|
|
IMHO, it is preferable to place every block of code within curly braces. It aids readability despite not being syntactically necessary. Also, I would declare each variable on a separate line.
Paul Marfleet
|
|
|
|
|
Thanks,
pmarfleet wrote: it is preferable to place every block of code within curly braces
I take it you are referring to the if statements.
I agree with you - I sometimes take shortcuts; however it helps others, reading my code, to avoid those shortcuts.
You always pass failure on the way to success.
|
|
|
|
|
That's right. For instance, within your loop it isn't immediately obvious which statements are dependent on the result of the if statement and which aren't. Placing all dependent statements within curly braces aids readability, even if this is only a single statement.
Paul Marfleet
|
|
|
|
|
GuyThiebaut wrote: I sometimes take shortcuts; however it helps others, reading my code, to avoid those shortcuts.
Not only does it help others, but it will help you in the long run as well. I have seen all too often someone (even the original author) modifying code sometime later (months to years), not paying attention and adding a line to an if block. The problem here was that the if block originally was a single line with no braces. The new line was added, and significantly changed the behavior of the code. Had the braces been there to start, it would have been completely obvious where the line was going and that it was properly inside the if block.
|
|
|
|
|
The variables that you declare in the class should be declared inside the method instead.
As the method is not using any data from the object instance, it should be static.
Method names are usually written in PascalCase, i.e. IsPrime.
To always use brackets around a block makes the code more readable, i.e:
if (testLimit % 2 == 0) {
return false;
}
If the code in the method has a singe exit point, it's easier to follow.
---
single minded; short sighted; long gone;
|
|
|
|
|
Thanks for all the information and help
You always pass failure on the way to success.
|
|
|
|
|
You can also look at the Framework Design Guidelines (either on MSDN or the printed book). These are the design guidelines Microsoft created after .NET 1.0 was released.
The important thing to remember about code style and standards is that they:- are guidelines
- are not set in stone
- should be consistent
- should be flexible enough to adapt to new languages and technologies within those languages
|
|
|
|
|
Thanks,
I get what you are saying regarding bracketting.
In some of the procedural languages I have programmed I have seen people using what are called "in-line ifs".
I have always avoided them, unless there is no other solution, for precisely this reason - the logic can be misunderstood or lost and new code added can cause all sorts of problems at testing (we do all test code don't we...).
Thanks for the reference.
I will look at this.
As you say standards need to be flexible as in my experience some businesses have their own in house rules on coding standards.
When I was trained in COBOL (no I'm not a Grandfather yet...) the trainers would get a ruler and measure code indentation, to the centimetre, on our code printouts 
You always pass failure on the way to success.
|
|
|
|
|
i got a realy strange issue with invoking code on a multi threaded application , it happens on thins function below:
<br />
private void closeForm()<br />
{<br />
if (this.InvokeRequired)<br />
{<br />
ShowFormCallback d = new ShowFormCallback(closeForm);<br />
this.Invoke(d, new object[] {});<br />
}<br />
else<br />
{<br />
try<br />
{<br />
goform.Close();<br />
}<br />
catch(Exception e)<br />
{ <br />
Console.WriteLine("Cant close the damn form " + e.Message);<br />
}<br />
}<br />
<br />
}<br />
<br />
}<br />
The Error is:
"Cross-thread operation not valid: Control 'player2' accessed from a thread other than the thread it was created on."
although on debug i see that when the closeForm() is executed
this.InvokeRequired has a "false" value.
and yet when the line: "goform1.Close();" is executed i get cross-thread operation not valid.
how is this possible, i have used this technique (given by the MSDN) in order to avoid such errors several times and never had problem with it,
so what could be the cause of such a thing?
Net
|
|
|
|
|
What does "goform.InvokeRequired" return? That is the control you are executing a method on, so it's really up to that control to determine if it needs an invoke.
|
|
|
|
|
oh oops , my mistake  , i wrote this.InvokeRequired instead of ,
goform.InvokeRequired , now it returns 'true'
Net
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
