|
DId you cast it (the form) to your form before you tried to access it?
draco_iii wrote:
All to no avail and I need to have access to this varible from anywhere in the program.
I suggest making a "static" class then to hold these variables.
MyDUMeter: a .NET DUMeter clone
"Thats like saying "hahahaha he doesnt know the difference between a cyberneticradioactivenuclothermolopticdimswitch and a biocontainingspherogramotron", but with words you have really never heard of."
|
|
|
|
|
Made the static class for the variable it look like this
<br />
using System;<br />
using Perpetual_Settings;<br />
namespace Brazen_Mail<br />
{<br />
public class Setting<br />
{<br />
public static Perpetual_Settings.PerpetualSettings test = new PerpetualSettings();<br />
static Setting()<br />
{<br />
test = new PerpetualSettings();<br />
}<br />
}<br />
}<br />
But when running the code I get this error.
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in system.windows.forms.dll
Additional information: File or assembly name Perpetual Settings, or one of its dependencies, was not found.
I can see the Properties and Methods from the class when trying access them via VS, but it craps out when I try and run the program.
|
|
|
|
|
Spaces in general is a BAD idea spawned from some VB coders on crack. NEVER use spaces. I assume your dll is called "Perpetual Settings.dll".
Spaces are used to space code elements, not making pretty names.
MyDUMeter: a .NET DUMeter clone
"Thats like saying "hahahaha he doesnt know the difference between a cyberneticradioactivenuclothermolopticdimswitch and a biocontainingspherogramotron", but with words you have really never heard of."
|
|
|
|
|
Thanks. As soon as I got the space out of the name it worked perfectly. There needs to be a an article about making a static varible class. It is the best way I have seen to have global varibles.
|
|
|
|
|
this.ParentForm returns a System.Windows.Forms.Form class type, not your derived class.
In fact, this.ParentForm is mostly used for UI logic. For your application logic, it's better to either let the two forms know about each other existence or, better, share a property bag class (better in terms of decoupling).
|
|
|
|
|
How do you go about letting them know about each others existance or at least letting the child forms see full existance of the main running form? I need to be able keep one set of the varibles not multiple instances so that they can be written to or read from by any of the child forms. Doing so, would allow less overhead and insure that all of the child forms are working from the same set of "settings".
|
|
|
|
|
I'm not sure if this is the correct way of doing things, but I have been able to access properties and function in parent/child forms like this.
ChildForm child = new ChildForm();
child.Owner = this;
((ChildForm)child).PublicProperty = MyVal;
Then you can access the parents public properties like this
((ParentForm)Owner).PublicProperty = MyVal;
((ParentForm)Owner).PublicFunction();
I know that this works, but is it the correct way of doing things? And if there is a better way of this, any example code on this?
|
|
|
|
|
This may or may not be useful to others, but seems to be a bug that may be a source of frustration for web service developers.
I was going through the walkthrough in msdn entitled
"Walkthrough: Creating a Distributed Application"
Everything worked fine until I got to the web service part.
Whenever the test app called the GetAuthors method the
web service method is not invoked, instead, I get a timeout error.
I pulled my hair out for days on this one and after trolling through the google newsgroups found a single post from someone who had found a problem when running a background process at low priority.
Ref: http://groups.google.ca/groups?selm=TUgx9.78009%24wG.281797%40rwcrnsc51.ops.asp.att.net&oe=UTF-8&output=gplain[^]
I was also running a background process but a different one. It's like the distributed processing SETI app. only its for a distributed computing cancer research instead.
Ref: http://www.grid.org[^]
Here is what he wrote and exactly what I found as well:
Conclusion: The Web Service "Invoke" code on the WebClient side is
succeptible to being locked out of processing time by an active background
process. However, once successful, this invocation is "cached" for a limited
amount of time and subsequent calls do not exhibit the lockout. However^2,
after a delay between invocations of t seconds, where t is some value less
than 181 seconds, subsequent invocations are again locked out.
|
|
|
|
|
Hi,
I'm working on a multi-threaded application that has Windows Forms/controls.
I'd like to have some controls handle some non-UI events that are spawned in
background threads. Currently this is causing me trouble because those
event handlers may create new controls, and only the Windows Forms thread
can do that sort of thing.
Right now I'm using an EventManager or EventSet, as described by Richter's
Applied .NET Framework programming. Both controls and non-controls might
subscribe to these events. The controls' event handlers may create new
controls, so the controls' event handler should be Invoked. Is there a clean
way to fire off event handlers if I don't know a priori if the event handler
is in a control?
Are there known ways to fire events generally where the subscribed event
handlers may be in controls (and need to execute in the Forms thread) or
not?
Thanks,
Arun
|
|
|
|
|
if (control.InvokeRequired)
{
control.Invoke(control.SomeMethod, new object[] {"bah", "boo"});
}
else
control.SomeMethod("bah", "boo");
MyDUMeter: a .NET DUMeter clone
"Thats like saying "hahahaha he doesnt know the difference between a cyberneticradioactivenuclothermolopticdimswitch and a biocontainingspherogramotron", but with words you have really never heard of."
|
|
|
|
|
Thanks, that'll do quite nicely! I had read about InvokeRequired a month ago and had forgotten about it.
|
|
|
|
|
I had this problem just as I started C# and it stumped me for 2 weeks (eventually JTJ came to the rescue), I will never forget it 
MyDUMeter: a .NET DUMeter clone
"Thats like saying "hahahaha he doesnt know the difference between a cyberneticradioactivenuclothermolopticdimswitch and a biocontainingspherogramotron", but with words you have really never heard of."
|
|
|
|
|
Hi everyone,
I was wondering if anyone might have some good resources for doing game development in C#, and also wanted to know your thoughts on doing games in C#, would C,C++,Java be better suited?
Thanks
|
|
|
|
|
The DirectX team recently released DX9, which has support for writing games in C#. I haven't looked at it in detail, but my first impression is that it will make writing DX code easier, but not easy, if that makes sense. You'll still need to learn about DX concepts.
If you choose to write in C#, there are a few disadvantages:
1) You need the .net runtime installed on the target machine
2) It will be slower than a C++ version, because you will be calling from C# code into native code. I don't know how much this slowdown is.
The advantages are that writing C# code is a lot easier than writing C++ code for most people.
|
|
|
|
|
I have a ListView sitting on an MDI tab (from the Magic library, if that makes a difference). If I set the tab's Dock property to DockStyle.Fill (and do the same with the ListView), the ListView control gets partially clipped by the status bar. I don't mind handing Resize events to keep things organized and prevent the clipping, but I'm wondering if there isn't a better way. Can the controls be told to size themselves correctly without an programmer intervention?
|
|
|
|
|
I can only assume that it's something to do with Magic's TabControl implementation, as I have done similar things with the standard TabControl without problem.
One possible workaround would be to set the DockStyle of the ListView to None, size it to fill the TabPage in the designer, then set the Anchor property to all sides (Left, Right, Top, Bottom).
|
|
|
|
|
That seems to work. Thanks, Furty.
|
|
|
|
|
Okay, here's a simplified version of what I'm trying to do.
I have a RichTextBox in a form for editing a text file; I've written a simple Find/Replace dialog (whose parent is the textbox itself).
Currently, when you hit "Find", it has to close the dialog so that you can see the selected text (selected by the RichTextBox.Find function). You can then use F3 to find again. If a RichTextBox doesn't have focus then the selection isn't visible, so there's no benefit to keeping the dialog open.
But what I'd really like to do is keep the Find/Replace dialog open while someone does as many find and replaces as they want.
Any ideas out there?
Paul
And you run and you run to catch up with the sun, but it's sinking
Racing around to come up behind you again
The sun is the same in a relative way, but you're older
Shorter of breath, one day closer to death - Pink Floyd, Time
|
|
|
|
|
Try passing a reference to your RichTextBox to the find form, and calling the RichTextBox.Find method from the actual find form. Make sure you use the Show() method to open your find form, rather then the ShowDialog() method.
|
|
|
|
|
Do any free .NET grid controls exist?
-Domenic Denicola- [CPUA 0x1337]
“I was born human. But this was an accident of fate—a condition merely of time and place. I believe it's something we have the power to change…”
|
|
|
|
|
So far ive only seen two, the one in the C# section of this site, and the other is one that i am working on, gone a bit on the back burner now, but i intend to put a little more effort into its production.
[Davide Icardi] http://www.codeproject.com/useritems/CSharpGridControl.asp[^]
[Mine] http://www.onyeyiri.co.uk/csharp/grid/[^]
[edit]
shouldnt of mentioned mine, no where near ready.
[/edit]
1001111111011101111100111100101011110011110100101110010011010010
Sonork | 100.21142 | TheEclypse
|
|
|
|
|
When you move a splitter with the mouse, a pointy black/grey background of the splitter is painted. This I would like to change.
I tried to use the Splitter_Moving event, but it doesn't work. Maybe my painting was overpainted from System.
Does anybody know how to change this or can give me a tip?
Thanks
Stefan
|
|
|
|
|
You can't that easily. The splitter window is drawn using an hardcoded private function :
private void DrawSplitHelper(int splitSize) {
Rectangle local0;
IntPtr local1;
IntPtr local2;
IntPtr local3;
IntPtr local4;
if (this.splitTarget == null)
return;
local0 = this.CalcSplitLine(splitSize, 3);
local1 = this.ParentInternal.Handle;
local2 = UnsafeNativeMethods.GetDCEx(local1, IntPtr.Zero, 1026);
local3 = ControlPaint.CreateHalftoneHBRUSH();
local4 = SafeNativeMethods.SelectObject(local2, local3);
SafeNativeMethods.PatBlt(local2, local0.X, local0.Y, local0.Width, local0.Height, 5898313);
SafeNativeMethods.SelectObject(local2, local4);
SafeNativeMethods.DeleteObject(local3);
UnsafeNativeMethods.ReleaseDC(local1, local2);
}
As you can see, the implementation never takes care of properties you may have set (like ForeColor, ...).
The only way to get around this is to write your own splitter window. But that requires significant work since all of the splitter methods are declared private, thus won't be inherited.
Using a decompiler however, that's not a complex task.
Good luck!
|
|
|
|
|
Thank you.
So it's possible but very difficult? So I can't derive from SplitterClass and than overwrite the DrawSplitHelper?
What do you mean with "write your own splitter window"? Do you mean to take the panel-class and than write the whole Splitter Functionality by my-self? That would be hard, wouldn't it?
It seams that you know really much about C#. Can you give me a tip or a direction how to solve this problem with the Splitter?
Thanks
Stefan
|
|
|
|
|
STW wrote:
So I can't derive from SplitterClass and than overwrite the DrawSplitHelper?
You can derive the class since it's not internal nor sealed but, since almost all methods are private, by inheriting the class you won't get them. (that's a basic inheritance rule).
STW wrote:
What do you mean with "write your own splitter window"?
I mean "write your own splitter window".
The splitter class is a System.Windows.Forms.control derived class, so basically you have to do exactly that, and implement all the stuff. Fortunately, the .NET splitter class is much simpler than the MFC Splitter Window (which acts as a container and provides a lot of implementation for scrollbars, etc.). Using your own implementation, almost the only thing you have to do is to provide OnMouseDown, OnMouseMove and OnMouseUp handlers, and call the native WIN32 SetCapture()/ReleaseCapture() whenever needed.
That said, although I haven't tried it, I would simply try to override Splitter.WndProc(ref Message m) and implement my own WM_PAINT handler. Just in case...
Good luck!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
