|
Well, since you should know the parent form's class name this is what I've done recently. I can't guarantee that it is the best method of doing it but I also haven't found any other solution:
private void Button1_Click(object sender, EventArgs e)
{
((AppForm)this.MdiParent).SomeMethodToOpenChild();
}
Casting the current child form's 'Form MdiParent' to the application's form type, then calling a method that opens the necessary child window. Like I said, I don't know how safe that is. But I believe you could check ahead of time like this:
if (this.MdiParent is AppForm)
((AppForm)this.MdiParent).SomeMethodToOpenChild();
I hope this at least gets you going in the right direction. 
|
|
|
|
|
If the form is an MdiChild, you can get a reference to its parent using the MdiParent property. If you want to set another form as a child of the same parent, it's pretty easy
If you want a MdiChild form to be both a MdiChild to one Parent and a MdiParent to another child form, you can't. It's not supported. A form cannot be both a MdiChild and MdiParent at the same time.
|
|
|
|
|
Great answer Dave. 
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
hi i am trying to do malloc in vs.net 2005 c# window form as i am trying to dynamically allocate memory for a array which i dont know the size.
am i missing a reference or something?
or is there some other way to do it?
please advice
|
|
|
|
|
neodeaths wrote: is there some other way to do it?
A simple declaration might look like this;
string[,] names = new string[5,4];
More information and examples can be found on MSDN[^].
--edit
If you don't know the size beforehand, there's two options;
I'd go for a generic list; it's dynamic and can be easily converted[^] to an array.
I are Troll 
|
|
|
|
|
if you don't know the size, how on earth is malloc going to be any good?
may I suggest you buy and study a beginners book on C# (or any language you choose), so you get the basics explained in a thorough and consistent way.
|
|
|
|
|
The only reason to use malloc would be if you're passing stuff to unmanaged code. If all you want is an array, you just need to declare it. you don't have to worry about memory management the way you do with C.
|
|
|
|
|
use a dynamic List<> or an ArrayList or any of the other nice things build into the .Net Framework (can be found under the System.Collections and System.Collections.Generic namespaces)
And then start thinking in .Net! Buy a book, learn the basics. Don't get confused by the "C-style syntax" of C# - this IS NOT C in any way!
|
|
|
|
|
Hi there,
Check this out. It happends with all programs i have installed. I have WinXP SP2. When i open any program, lets say Winamp for example, the program starts with 11.000 KiB of memory usage, i minimize the program and immediatly restore it and now it uses 1.500 KiB.
Why is this happening? Do applications need to start minimized and then manually restored to make use (and show in the task manager) of the proper memory space?
Again, it happends with every windowed app. This issue is kind of important to me right now because i have to show the efficiency of a demo, in terms of response time and memory usage.
Any thoughs about this? Please try it.
Thanks.
|
|
|
|
|
Heinz_ wrote: Why is this happening?
There's an amount of memory reserved to be used by your application
I are Troll
|
|
|
|
|
First, stop looking at Task Manager to get your memory stats for your app. It's lying to you.
Next, I suggest reading up on .NET Memory Management and Garbage Collector to understand how it really works.
A .NET application runs in something like a virtual machine, sort of like Java does. What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using. Since the .NET CLR handles memory management for your application, it has to get memory from Windows to allocate to your application. This chunk of memory is the Managed Heap and all of your application objects are allocated from it. When your app frees an object, the memory goes back into the Managed Heap, not back to Windows. This is why your app appears to use more memory than it actually does.
The .NET CLR tries to keep this pool of memory at a resonable level, constantly watching how your app allocates objects and trying to predict when it's going to need more managed heap. It doesn't take near as much time to allocate an object in the Managed Heap than if it had to go to Windows to request more memory, add it to the heap, then allocate your object. The reverse is also true. If the CLR determines that there is an over abundance of unused Heap, it can return some of that memory back to Windows. Or, can even release as much memory as possible if Windows starts to run low and needs it back.
When you minimize the app, it's no longer in the foreground. The .NET CLR trims back the Managed Heap to something closer to what your app is actually using and returns that released memory back to Windows.
|
|
|
|
|
Great answer Dave. I think every developer needs to get a basic understanding of the .Net CLR.
Sounds like you read my book.  (I haven't wrote any books)
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
That's OK. I don't read any books, so there's really no need to write one.
|
|
|
|
|
Richard Blythe wrote: Sounds like you read my book.
Dave only reads the back of cereal packets. His knowledge of IT is picked up by being in total harmony with the universe.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: Dave only reads the back of cereal packets.
How the hell did you know that?!
No, seriously?
|
|
|
|
|
I'll send you some box tops... 
The mind is like a parachute. It doesn’t work unless it’s open.
|
|
|
|
|
Thanks for this clear and concise explanation. Sometimes one doesn't know what one doesn't know - if you know what I mean! 5 from me.
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
Thanks for the reply.
I'm not using the task manager to get the memory stats in my app, i'm using GetProcessMemoryInfo() from the Win32 API wich is the same i guess.
The real thing is: Try this minimize-freemem thing with WinRAR and Task Manager. WinRAR is not .NET (.NOT for me  ). So, i think .NET is not the issue here. This also applies to Win32 and all subsequent wrappers.
Anyway, for my app i'm also using native Win32. Don't know why your reply is strictly related to .NET. "Windows Forms" is not .NET. WinForms is present also in COM programming (VB6 for example) and MFC so i guess i'm not in the wrong forum (unless this forum is specific for the System.Windows.Forms.dll .NET module).
.NET or not, my question has been answered anyway ("...What Task Manager is showing you is the memory that is RESERVED for the process, NOT what your app is actually using...").
Thank u very much.
-- Modified Monday, August 16, 2010 3:12 AM
|
|
|
|
|
Heinz_ wrote: So, i think .NET is not the issue here.
Actually, .NET increases this little "problem". Your app may be very small and not use any data at all and still take up 20MB of memory when started. When you minimize/restore the window, the memory "usage" may drop to 500K, or whatever...
|
|
|
|
|
hi i am using c# windowform 2005
i am trying to explore and learn if window form can manipulate mouse and keyboard movement e.g like a macro mouse to point 1,7 and etc
and what classes they use if it is possible
|
|
|
|
|
yes it is possible.
AFAIK you need P/Invoke for mouse automation, see functions SendInput and SetCursorPos in user32.dll; for keyboard automation the .NET System.Windows.Forms.SendKeys class could be sufficient.
For all of them, you must make sure you are talking to the right window, which needs to have focus; so you will probably need even more P/Invoke and use functions GetForegroundWindow, SetForegroundWindow, GetWindowText, and maybe more.
Warnings:
1. you probably need to include some delays, say Thread.Sleep(100), so the target application can react to your automation inputs (which otherwise would come much faster than a human user would provide them);
2. whatever you do it will not be absolutely safe. For one, there could still be a user typing/mousing around; second, target apps may suddenly throw unexpected stuff at you, maybe a dialog telling you the disk got full, the network connection was lost, etc.
|
|
|
|
|
My company has a winform application with hundreds of forms. The application is close to be released and management now want us to add application level security in it. So basically things like a user X in role Y can do certain things but should not be able to do other things. We cannot reply on the fact that all our clients will have windows domain.
My initial thought about its design is to have some kind of mapping in terms of UI elements in different forms and then make these UI elements read-only based on permissions. Just wondering if there are any patterns of implementing it and if anyone can point me to links for it? I have looked at Security Application Block in Micorosoft Enterprise Library and seem like it can be used for authenticating the users but its probably problematic if you are not on Active Directory (correct me if I am worng here)?
|
|
|
|
|
imak wrote: The application is close to be released and management now want us to add application level security in it
What an excellent planning and design system you have. This is so common it hurts (it is now going to bite you guys).
From a couple of decades of practical experience!
. Internalise you security, manage your authorisation in your application by mapping UI elements to roles.
. We use an AEDX field on a function (UI element) that allows a fine grain control
. Base your authentication on Active Directories, once they log on they are authenticated, then look up your internal authorisation tables.
. Create a base form that all your dialog/forms can inherit that will do your user validation.
We have a main menu and 95% of apps (we have about 15) only require security applied to this level (ie this user group can have the Customer function but has no AEDX rights on the form, therefore it is read only)
Adding security to a major app is not a trivial excercise and testing is a stone bitch! Good luck
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
How are the security roles going to be described to you? Usually in situations like this the business user will describe the security in terms of a business process rather than individial pieces of data. Something like "the accounting role can process invoices" rather than "the accounting role can update the following fields...". If your app is designed along similar business process flows, then the security can probably be applied to a few buttons and menu items or at the form level rather than lots of individual data controls. Mapping each and every UI element to a permission scheme can be terrible for performance. Since this is something that you distribute to multiple clients you also need to decide about how the roles will be managed unless you intend to force the same scheme on all of your customers.
|
|
|
|
|
this is the right time to add application level security. Never think about such things when you start writing your app. Always add security related things in a hurry short before release date - and of course don't waste time testing it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
