|
I need to get the actual designed size of a user control *after* the control layout has been performed. I found it in the InnerMostActiveContainerControl.CreateParams property (by looking around with the debugger), but I can't get to it via code.
Can anyone tell me how to retrieve this info? Even google only has four or five referrences, and none of them give me any info.
Alternatively, here's what I'm trying to accomplish.
I have a Panel on a form that's only 200x200 pixels in size. The panel is anchored to all four sides of the form (no, docking isn't an option). Several user controls of differing sizes are layered (and fill docked via code) into the panel, and all of them are *larger* than the panel that contains them. After PerformLayout is called, I tried to account for the size of the user controls, and adjust the size of the form by the largest dimensions, and the form resizes as expected, but the anchored panel doesn't resize with the form.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Sounds odd, but, if you know what size you want the form to be, and the panel fills the form, why not just also resize the panel in code ?
Why do you need the panel at all ?
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
Christian Graus wrote: if you know what size you want the form to be
I don't until the last user control is created.
Christian Graus wrote: and the panel fills the form
The panel isn't set to dock (and doesn't fill the form).
Christian Graus wrote: why not just also resize the panel in code
Because the panel can't exceed it's relative size. There are controls above and below the panel.
I just thought that if I set the anchor settings for the panel, and then changed the size of the form in code, the anchor settings for the panel would be honored, but they're not.
I figured that since the UserControl objects were being created in code and not added to the form via the designer, I could get the original designed size before adding them to the controls list in the panel.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: The panel isn't set to dock (and doesn't fill the form).
OK, I saw it doesn't dock, but I thought it anchored to the four edges still.
John Simmons / outlaw programmer wrote: just thought that if I set the anchor settings for the panel, and then changed the size of the form in code, the anchor settings for the panel would be honored, but they're not.
Yeah, that's odd, they should be.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
Christian Graus wrote: OK, I saw it doesn't dock, but I thought it anchored to the four edges still.
It is anchored on all four sides.
Christian Graus wrote: Yeah, that's odd, they should be.
I'm pretty sure that it's a layout issue, but I'm not sure how to go about solving it. In the designer, the form acts correctly when I drag it to different sizes, so I know the anchor styles are doing their thing. But if I re-size the form programmatically, nada.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I don't know where the values are coming from, but it insists that each user control is 376x214. This is freakin' absurd...
I also tried using SendMessage to force a resize, but until I can detect the actual size of the user control, I'm still hosed.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I figured out what's happening.
I have a class derived from UserControl. From that class, I derive a number of classes. When they're created, they call a function in the form class that gets their size and adjusts the for size so that the panel is large enough to accommodate the largest of the user controls.
public partial class MyControlBase:UserControl
{
}
public partial class MyControl1:MyControlBase
{
public MyControl1(MyForm parent):base(parent)
{
InitializeComponent();
parent.AdjustPanelSize(this);
}
}
public partial class MyControl2:MyControlBase
{
public MyControl2(MyForm parent):base(parent)
{
InitializeComponent();
parent.AdjustPanelSize(this);
}
}
public partial class MyForm:Form
{
public void AdjustPanelSize(MyControlBase control)
{
}
}
Since I'm calling the function as the base control class, it's using THAT class's size settings instead of the class that's actually calling the function.
If I add the line:
base.Size = this.Size;
BEFORE calling the AdjustPanelSize function, it works. In fact, I end up having to do that for any property I want to be used from the derived controls.
I guess inheritance isn't really inheritance in C# - this kind of code would have worked fine in C++.
|
|
|
|
|
Hi All,
I'm just rewriting a core function in an application I'm working on and was wondering what peoples thoughts are on the performance side of things.
I have a set of data that lives in a DataTable, the data in this DataTable is used to separate the data into lookups based on a key/value pairs. This suggests they should be Dictionary<string,string> (which is how I have in fact coded it) there are two lookups varying in size from 22 items to 220 items and two Dictionary<string,int> lookups that keep track of matches.
All 4 Dictionary lookups are declared static in the class and if any are empty or null at object initialisation they are all initialised in a single loop over the DataTable (which is itself set up as a thread-safe singleton).
The two main lookups are going to be looped over looking for matches thousands of times in the life of the app so getting them as performance tweaked as possible is really important.
Does this sounds like a sensible approach or are there alternatives that might perform better?
All the data in the look ups are upper cased strings, I've heard that C# actually performs string comparisons quicker if both are upper cased, does this actually stand up as correct?
Would appreciate any thoughts.
Cheers,
|
|
|
|
|
Sounds OK to me.
Jammer wrote: string comparisons quicker if both are upper cased
I doubt it, though without data to back it up, plus how much of that "saved" time is wasted by performing the upperification upperization?
However, why not try passing the Dictionary a System.StringComparer.CurrentCultureIgnoreCase?
|
|
|
|
|
|
Jammer wrote: The two main lookups are going to be looped over looking for matches
You should put whatever value you are matching on as the key in the dictionary, so that you don't have to loop through them.
A dictionary uses hash codes to quickly find items by key, so that is very much faster than looping through the data.
Jammer wrote: I've heard that C# actually performs string comparisons quicker if both are upper cased
I've never heard that. Case-sensetive culture-invariant comparison is faster than case-insensetive culture-dependent comparison, if that is what you mean.
If you use the dictionaries correctly, it will only do one or a few string comparisons to locate each item, so the speed of string comparions is hardly an issue.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: You should put whatever value you are matching on as the key in the dictionary, so that you don't have to loop through them.
Indeed, that's what I have done.
Guffa wrote: A dictionary uses hash codes to quickly find items by key, so that is very much faster than looping through the data.
Of course! Its not going to be looping as such is it.
Guffa wrote: I've never heard that. Case-sensetive culture-invariant comparison is faster than case-insensetive culture-dependent comparison, if that is what you mean.
Gotcha, thanks.
|
|
|
|
|
hallo i need to programmatically format a hard disk.
Apart from ShFormatDisk, it seems that there's a hope by using FMIFS.DLL or UNTFS.DLL.
Has anyone a piece of code to show me?
Out there there are just old broken links to sysinternals site regarding FMIFS.DLL.
Thanks in advance
modified on Friday, December 12, 2008 3:00 PM
|
|
|
|
|
Why do you want to format a disk? Are you writing a virus?
|
|
|
|
|
If he was it would be a sh*tty virus, no gain in formatting a disk. Maybe he means a removable storage device?
|
|
|
|
|
thanks for the interesting replies, it's curious that everywhere i find a thread for "hard disk formatting" there's somebody asking if it is for virusing. Sounds like if a programmer wants to write a scanner software, it is for duplicate identity cards... Evil Is Everywhere :P
BTW has anyone serious idea of how to write a function to erase an internal (no removable, no flash memory) hard disk?
|
|
|
|
|
Nah can't help you there, I can't see any possible gain at all for formatting an internal hard drive. Tasks like that should be done by a user without any programmatical assistance through any application not specifically designed for that, it can lead to accidental formats, which should be limited and not encouraged.
|
|
|
|
|
|
Thanks Uwe. Yes i tried, they mainly suggest ShFormatDisk.
I'm trying to give my end users/customers a clean restore environment without dos boxes and nags, using imagex, but i need to format the disk before applying an image.
|
|
|
|
|
solved: i launch a command line Process with FORMAT using /Y, an undocumented flag for the unattended mode 
|
|
|
|
|
Hi
Is there any possibility that I could cast an object through its handle.
For example, I have to do an estimation of objects and finally I get the handle of that object through GetWindow API call, now I know its type but how to retrieve that object and cast it for that specific type?
I am implementing it using a dll file.
Regards,
Mujtaba Panjwani
Tiger Softwares
Software Designer and Developer
VB.NET, C#, ASP.NET, VFP
|
|
|
|
|
What kind of handle - an HWND?
If so, there is no built in association between an HWND and an object.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
Hi
Thanks for the reply.
Yes, it is an HWND. To make it more clearer, the handle is of a IE's statusbar32 object, for which I know only the handle, now I want to manipulate its objects and add/remove other Microsoft Common Controls so I was thinking of a way to cast that object to comctl's statusbarclass and then manipulate it instead of throwing Messages and creating pane window etc. using API calls as I am not very good in that.
Hope I was clearer to specify my scenario and you would have the solution to it.
Regards,
Mujtaba Panjwani
Tiger Softwares
Software Designer and Developer
VB.NET, C#, ASP.NET, VFP
|
|
|
|
|
MAP Tiger wrote: I know only the handle, now I want to manipulate its objects
You'll have to use APIs unless there's some other programming model
built into IE, which I wouldn't know
Mark
.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
