|
BillWoodruff wrote: the PropertyGrid is using reflection to enumerate all the current controls on the Form
Huh? Why would it do that?
BillWoodruff wrote: Just wondered if anyone else had experienced this
I have not. My wild ass guess would be that it's about how you are using it. That statement is not about you, it means if I encountered that scenario I would assume it was something I had done.
Also, what version of .NET are you using?
and, your sig has now sent me off to do some studying. 
|
|
|
|
|
Hi Led Mike,
I am also asking "huh" 
And I first assumed it was something I was doing, also. I first was using the ProperyGrid on a separate form as a "floating window" where the form it was on had its Parent property set to the Main Form.
So my first hypothesis was that perhaps the dynamic communication between the two forms was causing some complex interop and marshalling of data back and forth.
So I moved the PropertyGrid directy onto the Main Form : same problem.
So then, assuming the fact I had some controls in the "virtual cells" of tableLayoutPanel, and that accessing perhaps are causing the delay, I ripped out the tableLayoutPanel, just put a few simple controls on the main form, and tested again : still a long delay after the first control is set as the SelectedObject for the PropertyGrid and the PropertyGrid becomes usable.
I have read elsewhere that the PropertyGrid ... at desgn time ... is using reflection to discover the attributes of controls or forms.
Using the principle of Occam's Razor, the simplest hypothesis is that when the control is set, when it's instantiated at run-time : it does a recursive walk through the inner object tree of the app and uses reflection to discover all control objects and their inner list of propertes to edit for each control.
If it didn't parse them first, and then somehow "cache" the clusters of properties, which can vary from control to control, how could it suddenly switch from being non-responsive for over 10 seconds to performing consistently fast as you're editing even such complex properties as the number of columns in a TableLayoutPanel ? And jumping from control to control, it remains fast after that initial load penalty.
But I do note that when used at run-time the Property Grid will omit any special UI Editors for collections and such : I consider that it doesn't break on those to be a "feature."
best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
|
|
|
|
|
BillWoodruff wrote: I have read elsewhere that the PropertyGrid ... at desgn time ... is using reflection to discover the attributes of controls or forms.
Well Visual Studio is doing that. I have no information to suggest that the PropertyGrid is doing it.
Perhaps I don't understand what you question is. Are you asking about the performance of it in Visual Studio or in your own app, which is what I thought.
I have used PropertyGrid extensively in many applications and have never seen the issue you describe.
|
|
|
|
|
Hi Led Mike,
At run-time, in my own app.
Suggest you do this :
1. create a simple WinForms project : add a PropertyGrid
2. throw several simple controls on the Main Form : like buttons, textbxes, checkboxes, labels.
3. in the form Load event loop through the controls of the form and add a click handler that will set the clicked control (except the Property Grid, of course) = the SelectedObject method of the PropertyGrid.
4. run the app : click one of the controls you've wired up with a Click event: the PropertyGrid will load soon enough, but note the long delays before you can select a property and edit it in the Property Grid.
5. Note that once you can select a property to edit in the Property Grid, reponse time for updating the actual controls is very fast.
best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
|
|
|
|
|
I've just tested this on my system and the response feels instant - no noticable delays at all.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
Ah, now I get what you are doing. Of course it is using Reflection please ignore my previous crazy sounding replies about that. Apparently I was suffering from idiocy there for a while.
As Davey says it runs instantly on my machine which is underpowered compared to yours. (.NET 3 VS2008)
|
|
|
|
|
Hi, Friends, thanks for so much for checking this out !
The only hypothesis I can think of at this point is : perhaps it's something to do with the Beta code in VS 2010 : extra levels of object/event checking, internal Form structure ?
About the only thing I haven't done is try instantiating the PropertyGrid at run-time rather than at design-time just to see if there's any difference in modal behavior.
I think I'll go ahead and report this as a "bug" to MS, so I can have the "fun" of getting multiple e-mail messages about how the issue is "closed" and they don't consider it an issue The last one I reported was a completely incorrect statement in the MSDN documentation saying a certain control had a certain ability : I received about ten e-mails on this, none of which ever acknowledged the error in the documentation, or indicated any plans to edit it.
best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
|
|
|
|
|
It's possible what you are seeing is related to performance concerns in VS2010 but to be more certain you should test the same solution in VS2008 as well.
Based on your other posts, it sounds like you are creating an application containing a property grid and, at runtime, displaying the public properties of a given UI element in the property grid.
No matter what, when you set the SelectedObject property of the property grid to any object the default behavior is for the property grid to reflectively bind to all public properties of that object. The only thing that changes this behavior is if the object implements ICustomTypeDescriptor and provides an implemenation of GetProperties() to return the "public" properties that are available.
Instantiating the property grid at "run-time rather than at design-time" will make absolutely no difference in it's behavior. Likewise, having the property grid in a dialog or on the main form will also have no difference.
I'm interested to know if you are doing this purely as a test project or actually have real-world scenario you are trying to solve with this implementation. We make heavy use of property grids at work, both letting the grid do it's own binding and informing the grid through GetProperties() and have had very few issues. (This is all in VS2008.)
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
|
|
|
|
|
Hi Scott,
Thanks for taking the time to reply !
Scott Dorman wrote: to be more certain you should test the same solution in VS2008 as well.
As I mentioned in a previous post, right now my machine with VS2008 is "down."
Scott Dorman wrote: Based on your other posts, it sounds like you are creating an application containing a property grid and, at runtime, displaying the public properties of a given UI element in the property grid.
Not exactly : there is an application with a kind of "virtual property grid" (using a TableLayoutPanel which can have one and one-only control per "virtual cell"). The PropertyGrid is used only to show, and allow editing of, the TableLayoutPanel itself, and any selected control within one of its "virtual cells." I say "virtual cells" because as you probably know the TableLayoutPanel exposes only Row and Column collections, not "cells."
Scott Dorman wrote: if the object implements ICustomTypeDescriptor and provides an implemenation of GetProperties() to return the "public" properties that are available.
Very timely : I have just been studying the example in Matthew McDonald's Pro Win Forms 2.0 book where he demonstrates using ICustomTypeDescriptor to edit the properties which will appear in the PG.
Scott Dorman wrote: Instantiating the property grid at "run-time rather than at design-time" will make absolutely no difference in it's behavior. Likewise, having the property grid in a dialog or on the main form will also have no difference.
Exactly the reason why this anomaly confounds me
Scott Dorman wrote: I'm interested to know if you are doing this purely as a test project or actually have real-world scenario you are trying to solve with this implementation.
Both.
This is a one-off non-public little application whose job is to produce a translation into a subset of HTML (required as input for a 3rd. party control) of a Table of controls and content. It is much easier for me to build a "mock table" at design-time taking full advantage of the ability to set Dock and Anchor properties of controls and content within a "virtual cell" of a TableLayoutPanel, and then parse that into the required subset of HTML, than it is to "switch my head" into HTML and generate a complex table in which the values of many properties will have to be escape-quoted.
It's also typical of the way I study programming in that I pose problems to myself which require me to get hands-on with controls like the PropertyGrid and TableLayoutPanel, and write small, hopefully re-usable, utilities.
best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
|
|
|
|
|
With VB 2008, I'm writing a text editor that resembles a word processor - 8.5 inch wide RichTextBox centered in the main window, etc. What I haven't figured out is how to place a vertical scrollbar on the right side of the window (instead of using the RTB's built-in scrollbar) and having it behave like the RTB's scrollbar.
Since the RTB's dock property is set to Fill (it's in a panel control), I can't really use the panel's autoscroll. I'd appreciate any pointers on how to make the VScrollBar, docked in the panel, function as the RTB's scrollbar.
Thanks!
AB
|
|
|
|
|
This article[^] does something similar although the GetScrollPos will fail with ERROR_NO_SCROLLBARS because your RichTextBox has ScrollBars set to none. The solution of your problem is probably by using Win32 API functions like GetScrollInfo[^], SetScrollInfo[^] ...
I never did something like this nor used these function before and I don't know if they will work or not. I'm not sure if you can achieve it using WPF but it may be easier.
Eslam Afifi
|
|
|
|
|
Hi
I need to get Operating System name using c#
I am using vista OS.
In my app i used
System.Environment.OSVersion
but it shows Microsoft Windows NT 6.0.6001 Service Pack 1
plz help.
Thanks in advance....
|
|
|
|
|
Hi,
you can find a descriptive string in the registry at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName
Luc Pattyn [Forum Guidelines] [My Articles]
DISCLAIMER: this message may have been modified by others; it may no longer reflect what I intended, and may contain bad advice; use at your own risk and with extreme care.
|
|
|
|
|
myms.net wrote: 6.0.6001
This holds everything. There is a page in MSDN which reveals the meaning of the number. (I dont have the link right now but it does exists).
जय हिंद
|
|
|
|
|
d@nish's reply above prompted me to have a search for a way to do this without using the registry (nasty on vista especially). Came up with this quickie which could do with some work, but does the job.
public static string GetOSFriendlyName()
{
string result = string.Empty;
ManagementObjectSearcher searcher = new ManagementObjectSearcher("SELECT Caption FROM Win32_OperatingSystem");
foreach (ManagementObject os in searcher.Get())
{
result = os["Caption"].ToString();
break;
}
return result;
}[Edit] reguires a reference to System.Management and the same adding to your usings [/Edit]
[Edit2] Useful reference MSDN[^] [/Edit2]
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
This[^] is what I was speaking of.
जय हिंद
|
|
|
|
|
Scenario :
1. create a WinForms project
2. at run-time create another Form (with TitleBar) and set its Parent Property = MainForm
3. Note that you can drag the child Form around by the TitleBar and move most of it outside the Main Form's bounds. If you really "work" at it (and particularly if the child Form's FormBorderStyle is set to something like FixedToolWindow [and the child form's Text property is ""]), you can manage to get the Form so "virtually outside" the Parent's bounds that you can't recover mouse control drag-ability over the child form.
4. But in general, the end user cannot (and hopefully will not) move child forms so far outside the "bounds" they'll lose control over them.
All of which leads to this observation/question : it seems to me the design of behavior of child forms could have been to restrict their movements so all of their current visible area would remain within the bounds of the parent Form : or at least to have given the programmer the option of having them so restrained.
... edit #1 ... I meant to say that, to me, the fact that the child form will be automatically moved when the parent form is moved, keeping its relative position to the parent form's Top and Left properties : suggests that keeping the child form "in bounds" on a titlebar move would be ... uhhh ... kind of "congruent." ... /edit #1 ...
If the child form is moved by its TitleBar, you pretty well have to write a WndProc to keep its bounding rect inside the current parent Form bounding rect. And I have yet to find a "flicker free" way of doing that (but I'm working on it).
Curious what you think about this aspect of WinForm behavior.
And, while we're at it ... why have a separate 'SetParent method which duplicates the functionality of Form.Controls.Add(... someForm ...) ?
thank, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
|
|
|
|
|
Hi,
I need to send a mail when i click submit button.
in the mail body have to display data from text box.
and this text box having so many lines data... i used multiline = true
text box data like..
aaaaa
bbbbbb
ccccc
problem is that ...
when i receive the mail the text box data has displayed in single paragraph...
like..
aaaaa bbbbbb ccccc
here i used
msg.IsBodyHtml = true;
Thanks in Advance...
|
|
|
|
|
CRLF is ignored in HTML. You have to replace the newline characters in your text with HTML equivilent formatting, I think the tag is <BR>, before you put it in the body of the mail message.
|
|
|
|
|
Hi all,
my requirement is to display multiple envelopes in one word document
i can add only one envelope using following code
CODEDim Act As Microsoft.Office.Interop.Word.Envelope
Dim WordApp As New Microsoft.Office.Interop.Word.Application
AddHandler WordApp.Quit, AddressOf WordOnQuit
Dim Doc As Microsoft.Office.Interop.Word.Document = WordApp.Documents.Add
Act = Doc.Envelope
WordApp.Selection.TypeText("VB.NET Rocks")
Dim strAddr As String
Dim strReturnAddr As String
strAddr = "ADDR" & vbCr & "123 Skye St." & vbCr & "OurTown, WA 98107"
strReturnAddr = "retADDR" & vbCr & "456 Erde Lane" & vbCr & "OurTown, WA 98107"
Act.Insert2000(Address:=strAddr, ReturnAddress:=strReturnAddr, Size:="Size 10")
WordApp.Visible = True
i want to add more than one envelope in word doc
Thanks in advance
|
|
|
|
|
Hello folks,
There is a UserControl (MyUserControl) that contains a container control (MainGroupBox) on it's surface (Dock.Fill). The question is how to place controls on MainGroupBox when user drags them into the MyUserControl in Design mode. I marked MyUserControl with ParentControlDesigner attribute. Now it accepts controls but places them behind the MainGroupBox. I tried to remove controls from MyUserControl and place them into MainGroupBox on ControlAdded event, but it seems it doesn't help.
I tired in vain to solve the problem from last weekend 
Does anyone know the solution? Any suggestions?
Thank you in advance.
Everything is possible!
|
|
|
|
|
Hmm... I think that I see work-around here.
We can tune z-index of MainGroupBox in order to show it behind all other controls like following:
private void CheckableGroupBox_ControlAdded(object sender, ControlEventArgs e)
{
gbMain.SendToBack();
}
But it is a trick, and controls' nesting is still wrong.
Everything is possible!
|
|
|
|
|
Dear All,
Am Using Epson BA-T500 printer. Manufacturer has provided a dll to print but its printing for arabic only question mark. but manufacturer has sent me a testing tool, its printing arabic correctly. I am coding in Vb.net 2005. so please let me know your ideas.
Thanks a lot
Regards
Azeem
|
|
|
|
|
If the printer is working with the test tool then look into your delivery of the data, make sure all the data is Nvarchar etc.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Its is not nvarchar but string.
I can able to display the arabic text in a message box
Regards
Azeem
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
