|
This is not a framework bug. It is probably ITunes hijacking your clipboard. I have seen similar behaviour in Adobe Acrocrapread and VNC.
|
|
|
|
|
I know this is a simple question but I would like to know How and Why this works;
Lets say I have two forms : Form1 and Form2 where Form1 is the main form. I am creating a Form2 variable by clicking a button in Form1 as seen in the code piece below.
private void button1_Click(object sender, EventArgs e)
{
Form2 myForm2 = new Form2();
myForm2.Show();
}
Why am I able to see form2. Because myForm2 is a local variable and just after it is shown, the function button1_Click terminates. So I mustn't be able to see Form2.
NOTE-1 : If you try the same with MS VC++ you will not be able to see Form2 .
NOTE-2 : I know in .NET variables are not deleted when they are out out of scope. Garbage collector does it. Bu in an other function I tried GC.Collect(); which forces the garbage collector but Form2 still remains, it is not deleted.
Regards
|
|
|
|
|
Hi,
a variable is visible ("in scope") as long as you are within the first pair of brackets {}
that encloses its declaration, so myForm2 lives only inside your button1_Click method.
The Form it refers to is an object, calling Show() makes it visible AND keeps it alive,
even when button1_Click returns and hence variable myForm2 fades away. Once visible, the Form
does not need the variable, it has its own life. You would have to close the Form somehow
(by clicking a Close box, or by calling the Close() method) to end its useful life and make it
collectable.
|
|
|
|
|
Thats the point; "Once visible, the Form does not need the variable". I just can't understand why and how?, sorry
But thats not the case in MS VC++. Once you create a dialog class and if the object is out of scope, the form is also deleted. Right?
There are strange things going behind c#
|
|
|
|
|
zafersavas wrote: There are strange things going behind c#
Oh no, if anything is strange it is in the C++ world.
A visible Form remains alive without a reference; same is true for a file you create on disk,
it does not get deleted when your file variable vanishes.
BTW dialogs get shown using ShowDialog() which does not return until the Dialog gets closed.
|
|
|
|
|
That's because the Form class is just a wrapper in the .Net runtime environment to manage a Windows API window handle. Creating a form and calling its Show method creates a window handle, and the window handle will remain until it is released (which happens when the form's Dispose method is called, be it from code or by Garbage Collecgtion). All these .Net classes handling windows API (or COM interop, which is even worse) have been designed to make life easy as long as you don't think about it too much. Soon as you start thinking it looks illogical and only reveals its logic when you read up on the System.Runtime.InteropServices namespace.
Being an old C hand you'll know much better than I what happens to window handles and things when they're not released. All I know is that when I detect a memory leak I have to look into the interop hell unless I can find an easy way (within .Net) to clean things up. That's twe price we pay for using a comfortable top level language like C# instead of ATL and MFC.
|
|
|
|
|
The variable contains a reference to the Form instance, a copy of that reference gets passed on to the Window Manager (or whatever), at which point your app and the whatever both refer to the instance, even when your reference is destroyed the whatever maintains its reference.
|
|
|
|
|
When ever you create a form and show it, a reference to the form is added internaly. There is a property of Application Object named "OpenForms" which returns a read only FormsCollection containing all the forms opened by the application. Since a reference is held to the form object even though your local variable is collected by gc, the form does not get collected. You can access the form through that collection and call the close method on it to close the form. Then the form is removed from the OpenForms collection and will be collected by the gc.
HTH
|
|
|
|
|
Thanks. I understand now; You can reach to the form by Application.OpenForms[1] .
This makes sense
|
|
|
|
|
dear ali rafiee
please send the mail for me
I am not speck EN language
i'm sorry for me
then
send mail to Dehghani.Fazel@gmail.com
or
o2_ir@yahoo.com
thanks
|
|
|
|
|
Maybe you should contact him through his member page or through which ever of his ten articles is interesting you?
Dave
|
|
|
|
|
For the record, when you get spam on those two addresses, it won't be from CP, it will be from people who scour the web looking for people dumb enough to post email addresses publically.
Christian Graus
Please read this if you don't understand the answer I've given you. If you're still stuck, ask me for more information.
|
|
|
|
|
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
When i added a datagrid to my form on the left side it display an asterisk before the very fast column. Is there anyway i can eliminate it. Thanks
|
|
|
|
|
netJP12L wrote: Is there anyway i can eliminate it.
Try looking at the properties of the control.
led mike
|
|
|
|
|
netJP12L wrote: the very fast column
I you mean to the left of the last row, it indicates that the user can add rows.
You can disallow the addition of rows with AllowUserToAddRows = false
|
|
|
|
|
I am using the AddInParameter to add a Int32 value as a SQL paramter. The problem I am having is that it is possible for this value to be null. When I try using logic to return either the int value or a DBNull value as the parameter, because the parameter type is DbType.Int32 I get a build error. How can I, based on the value of the insert integer, either add the actual int value or a DBNull value in the AddInParameter method?
Thanks,
Steve
|
|
|
|
|
Not sure what you're saying; can you post the code and exception?
|
|
|
|
|
After doing further research I was able to get it working. The working code is as follows:
if (predicateTable["CollectionNumber"].ToString() != "0")
db.AddInParameter(cmd, "pCollection_Number", DbType.Int32, Convert.ToInt32(predicateTable["CollectionNumber"]));
else
db.AddInParameter(cmd, "pCollection_Number", DbType.Int32, DBNull.Value);
Thanks,
Steve
|
|
|
|
|
It occurs to me that for a library that supports .net 2 to include support for Extension Methods when compiled with later versions, I should use something like:
public static SomeType
SomeMethod
(
# if SomeConstant
this
# endif
SomeType Param
)
{
...
}
But is there a built-in constant to do that? I could easily define one myself, but it wouldn't be standard.
For command-line builds I can easily add a define to C:\WINDOWS\Microsoft.NET\Framework\v3.5\csc.rsp,
but that doesn't help with Visual Studio builds. I can add the define to the project properties, but I'd have to add it to each project that might contain Extension Methods, and remove it if I have to switch the target framework back to 2 (for whatever reason).
Does anyone else have a way of dealing with this issue?
Is there simply a better/more-standard way of doing this already?
|
|
|
|
|
Unfortunately there really aren't any built in conditional symbols like you are looking for. The best/only option is to define a symbol yourself.
If you are compiling using VS2008 and the multi-framework targeting features, check out this blog post[^] by Daniel Moth. He shows how to get extension methods to work in .NET 2.0. You would still need to define your own symbol, but you would only need to have it in one place (around the .NET 2.0 extension attribute class).
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Well, I knew about the Attribute, and I really wish they had simply allowed the use of it to decorate methods directly rather than mangling the language, but they didn't ask me. And there are other things I don't like about Extension Methods, but that's just me.
Anyway, I copied his Attribute to my library, and it compiled in VS 2008!
At the command-line, using the V3.5 CSC.EXE, I got
warning CS1685: The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\Projects\PIEBALD\Attributes\ExtensionAttribute.cs'
as expected.
But the V2.0 CSC.EXE doesn't like the this syntax, likewise as expected.
So that's no solution.
|
|
|
|
|
Right, the .NET 2.0 compiler won't like the syntax. You will need to use the .NET 3.5 compiler but target the projects to the 2.0 Framework.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Scott Dorman wrote: .NET 3.5 compiler
I think I'd call that the C# 3.0 compiler.
|
|
|
|
|
PIEBALDconsult wrote: I think I'd call that the C# 3.0 compiler.
Yes...I was thinking about MSBuild, which in .NET 3.5 is marked as version 3.5. It's still the C# 3.0 compiler. Aren't these version numbers great?
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|