|
It is updating textBox1 in a new instance of frm1. Try something like below;
this.textBox1.Text += ThisText + System.Environment.NewLine;
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
ormonds wrote: Form1 frm1 = new Form1();
This creates a new instance of Form1 and updates the textbox on the new instance. Remove the line and change frm1.textbox1 to this.textbox1 (this is not required but will help you to identify the source of the control).
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
|
I read the daily CodeProject news, and came this article:
tps:
It is about C# finally getting multiple inheritance, kind of like C++, albeit through interfaces
I am very excited for this.
But when will this come out for say VS2017?
And I am referring to something like an official patch or update and/or maybe the next Visual Studio.
The article goes int details that this feature will only be for CoreCLR, which I've not tried yet.
Is there any news on it going to regular .NET Framework?
Also, how will custom attributes work with default interface methods?
This is something I've wanted since C#'s inception. It will greatly improve code STABILITY, re-useability and sharing, even more so than extension methods. I only wish C# would go full bore multiple inheritance so we can have multiple constructors getting launched.
But before going, I really want to just harp on my statement about STABILITY.
I can truly say that for 20+ years of C++ development, with multiple inheritance, I never ONCE even slightly encountered the "Diamond of Death". It was never an issue. C++ multiple inheritance allowed code to be re-used, over and over and over again, which meant, code got more and more tested as time progressed. that translated to better and more STABLE code.
When C# prevented multiple inheritance, and especially in the few years before entension methods, code in C# was cut/copy/pasted over and over and over again, causing old code with problems, to get cloned in their BAD-STATE, and then re-used for all time, until someone came out and hunted each and every instance of the clones down, and got rid of them. This cloning syndrome went on until extension methods came out, which was pretty much from 2001 till 2010.
But even after 2010, in my experience, there were so many people still harping about the "Diamond of Death", that they actually gimped development companies, to not allow extension methods. These ~people~ forced all development to have to cut/copy/paste code, over and over again, even if it was known to not be optimal and/or maybe even out right have BUGS.
|
|
|
|
|
Member 10474771 wrote: It is about C# finally getting multiple inheritance, kind of like C++, albeit through interfaces
I am very excited for this.
No, it is not. You can already assign multiple interfaces to a class.
It is about duck-typing interfaces, and how this creates a multiple-inheritence problem.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
WHAT?? Did you really read the article or just skim it?
No, we're NOT getting the ability to inherit from multiple classes.
We're getting default implementations of interfaces so you don't have to copy the same method implementation into all of the classes that use the interface.
It DOES NOT SOLVE the "Diamond of Death" problem, but, instead, will INTRODUCE IT into interface inheritance.
|
|
|
|
|
Eddy is right: it doesn't do any such thing. Read it more carefully, and you will notice this bit:
Quote: It means that a class doesn’t inherit members from the interfaces it implements
It just allows a default implementation so interfaces can be expanded without breaking the existing codebase: those default methods cannot be referenced on implementing classes unless they are either specifically implemented, or the instance is cast as the interface type.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I know I am going to be embarassed when I see the answer, but here goes. I have a simple app which looks like this:-
namespace ThisProg
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
form = this;
}
private void Form1_Load(object sender, EventArgs e)
{
textBox2.Text = "Initialising.....";
Refresh();
button1.Enabled= false;
}
public static void FinishOff(int ErrorLevel)
{
button1.Enabled = true;
}
private void button1_Click(object sender, EventArgs e)
{
System.Environment.Exit(1);
}
}
}
I've tried enabling the button using this.button1, Form1.button1, same error. Help much appreciated.
modified 21-Feb-19 3:45am.
|
|
|
|
|
Get rid of the "static" in your FinishOff method header.
|
|
|
|
|
There are two types of "elements" that a class can have: static elements, and instance elements (where an element is a field, property, method, event, or delegate)
A static element is shared by all instances, and is accessed via the class name.
An instance element is unique to each different instance of the class and is accessed via the variable holding the instance reference.
Think about cars for a moment: all cars have a colour - but which colour it is depends on which specific car you are talking about. My car is black; your car is red; this car is green; that car is blue. Colour is an instance property of the Car class because you need to have a specific instance of a Car in order to ask the question "what colour is it?" - you can't say "what colour is a car?" because it's meaningless without saying which car you mean.
But cars have static properties as well: you can ask "how many wheels has a car?" because all cars have four wheels. (If it had two, it would be a motorbike, not a car)
And that's important, because if you want to affect a Car (start the engine for example) you have to be referring to a specific vehicle - and inside a static method you are not talking about any particular Car, you are talking about all cars, and it's just not going to work to sat "start the engine" and expect all cars engines to run.
So when you declare a static method, it can't access anything in your class that isn't also static.
You want to access a instance button, so you need to use a instance method by removing the keyword static from it;'s declaration, as Dave has said.
Does that make sense?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thank you both, excellent explanation. You should write a book.
|
|
|
|
|
You're welcome!
ormonds wrote: You should write a book.
Who buys books any more? 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Have you not read "The Cruel C"? 
|
|
|
|
|
I am working with OpenXML SDK 2.5.
And I want to get all comment in a sheet of worksheet.
I can get text of shape, but I can not get properties of shape: position, width, height..
Please help me!
|
|
|
|
|
|
I am writing a little utility class, using PrincipalContext, UserPrincipal APIs that do some common Active Directory operation that we need.
I am testing with a console app at the moment.
My problem is, even though I create my PrincipalContext with admin user name and password, like this:
new PrincipalContext(ContextType.Domain, Server, Admin, Password)
My test console app only successfully works when run in Administrator mode console.
Do I really need that?
Or am I missing something?
[EDIT]
Never mind, when I run it remotely (i.e from my own machine instead of on the AD server) it works fine and doesn't require admin console.
Kinda strange....
modified 18-Feb-19 19:40pm.
|
|
|
|
|
I am trying to override the OnPaint and OnPaintBackground methods for my Application's main form. For some reason neither of the methods are being called EVER. They are completely ignored. What am I doing wrong?
|
|
|
|
|
Without seeing the code, we can have no idea whatsoever - heck, we don't even know what environment you are working in - WinForms. WPF, web app - and that can make a difference!
So show us the relevant code fragments, tell us how have you tested it, how you know it's never getting called, and what environment it is working in.
Help us to help you!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I have no idea what you would want to see. Other than than the fact that I am using a regular System.Windows.Forms form, I have no idea what else matters. All that I should need to do is write an overridden onpaint method... doing this has worked in other applications. that is the only thing that I know is relevant. I have simply written a method override. Here is the content but its all commented out because except for the call to the base method because it wasn't working. Putting a break point in here indicates that the method isn't being executed at all. It is working fine in other applications where I have overwritten the OnPaint method.
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
}
|
|
|
|
|
And you are right - that should work for WinForms, and a breakpoint should be hit.
And I'm sorry if this sounds like you don't know what you are doing, but I can't see your screen, so we need to start with basics.
1) Are you testing under the debugger?
2) Have you checked the OnPaint override is in the right form class?
3) Have you tried handling the Paint event for the form via the designer?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OK ... that doesn't helps ...
My questions are :
- you work with FORMS ...?
- you have created you own customized Form (I call it myForm) which derives from FORM ...?
- on that myForm you overrided the Method OnPaint ...?
- you have tested how it works with another Form (perhaps called Form1) which derives from myForm ...?
- why are the code-parts in your sample code commented out ...?
If you answer all of these questions it is perhaps possible to help you ...
|
|
|
|
|
Stupid question, but why is all the code commented out?
|
|
|
|
|
Hello all who have made comments. I am replying to my own comment so that I can address all of your comments in one reply.
All of you except for OriginalGriff are asking questions that I have already implied or explicitly written answers too:
Perhaps some of you don't speak English so I will clarify. This statement implies that the code I provided above is in a class derived from System.Windows.Forms:
"Other than than the fact that I am using a regular System.Windows.Forms form"
As for why I commented code out, I answered that question with the statement:
"Here is the content but its all commented out because except for the call to the base method because it wasn't working."
If you don't understand any of the above statements, then ask about that. Otherwise please don't ask questions that I have already answered. It wastes everyone's time. For my part, I probably could have written that second statement better as:
"Here is the content but it's all commented out because, except for the call to the base method, because it wasn't working."
OriginalGriff:
1. Yes
2. Yes
3. No. I did not want the form drawn normally under certain conditions.
EVERYONE:
I wrote a test program to both figure this issue out and move forward with my purpose since that test program is working correctly. I have learned that overriding OnPaint will not accomplish what I am currently trying to do (which is to make the application into a desktop widget when the user decides... that means drawing it as part of the desktop). However, I would still like to troubleshoot this in case I need to override OnPaint for another reason... chances are good I may need to since this is a very customized form.
|
|
|
|
|
I just tried something similar (using the code you posted) and it works every time. There must be something else in your form/project that is preventing it calling your OnPaint override.
|
|
|
|
|
Yeah. I know. I tried it again in the newer "test" app (as I mention in my most recent post above). It works fine. I still can't find anything wrong with the project app. I am hoping someone will have an idea of what could possibly get in the way of the override being called.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
