|
the problem i wanto solve is the datagridview must be locked but its vertical and horizontal scroll bars must be active
sas
|
|
|
|
|
What do you mean by locked? Don't allow the uses to edit it then.
only two letters away from being an asset
|
|
|
|
|
sir dont u understand my qestion its simple i have written the following code
datgridview1.enabled= false;
the problem is that the scroll bars are also disabled i want the scroll bars to be active
sas
|
|
|
|
|
sajid.salim.khan wrote: dont u understand my qestion
Apparently not.
Again, what is the desired outcome you are looking for? Do you want to display the datagrid to the user with the ability scroll, but without the ability to edit records?
If this isn't what you want, perhaps you need to take a few moments to think about it, and describe your problem better.
only two letters away from being an asset
|
|
|
|
|
I you want to display the datagrid to the user with the ability scroll, but without the ability to edit records
sas
|
|
|
|
|
Then don't put it in edit mode How much simpler can it be? What don't you understand?
only two letters away from being an asset
|
|
|
|
|
I look over some projects in CodeProject about creating FolderViev, FolderTreeView etc. in An "Explorer Style" and I see everywhere are used shell operations. Is that the only one way to do controls like this? Isn't there any simple method? Does C# and .Net provide owns classes and methods including shell instructions, or I have to write it always myself? And I have one mor questions: Is there any reason that everybody use shell to manage folders instead of using such C# classes like Directory[info], File[info] and others classes included in System.IO namespace?
|
|
|
|
|
Don't cross post in multiple forums.
Krecik_PL wrote: and I see everywhere are used shell operations. Is that the only one way to do controls like this?
What operations?? Perhaps you could point to an example?
Krecik_PL wrote: Isn't there any simple method? Does C# and .Net provide owns classes and methods including shell instructions,
Yes, everything under the System.IO namespace. But that also depends on what you mean by "shell instructions".
Krecik_PL wrote: Is there any reason that everybody use shell to manage folders
Because that "everyone" doesn't know what they're doing.
|
|
|
|
|
First of all I am sorry for crossing post. My mistake...
Dave Kreskowiak wrote: What operations??
For Exmaple Extracting icons from file system. I know there is System.Drawing.Icon.ExtractAssociatedIcon in .Net class but it takes icon only from file. What with folders and such virtual folders like "My Computer", "Desktop", disks, CD-ROM's etc? In article "C# File Browser" or "FilesListBox" autors use the shell to do this. Is there any other way?
Others samples are for expamle DragAndDrop support or System context menu used in Windows Explorer.
Dave Kreskowiak wrote: Because that "everyone" doesn't know what they're doing.
Saying "everyone" I don't mean all programers, but autors of some articles I look trough. Want you say that using the shell in C# is bad idea in some implements??
-- modified at 14:15 Monday 1st October, 2007
|
|
|
|
|
Krecik_PL wrote: For Exmaple Extracting icons from file system. I know there is System.Drawing.Icon.ExtractAssociatedIcon in .Net class but it takes icon only from file....Is there any other way?
The article you're talking about uses the Shell's API, not shelling out to another process, to grab the icons. No, there is no other way to do this.
Krecik_PL wrote: Dave Kreskowiak wrote:
Because that "everyone" doesn't know what they're doing.
Saying "everyone" I don't mean all programers, but autors of some articles I look trough. Want you say that using the shell in C# is bad idea in some implements??
I said this because I thought you were talking about shelling out to the command prompt to do things like rename files, copy files, doing whatever to files.
You didn't say anything about grabbing icons from anywhere.
|
|
|
|
|
You have right - I don't specify precisely my question - Shell's API is more adequate then shell instructions. I thought about more advenced operations provided by Shell's API to manage Windows namespaces.
Thanks for the answers...
|
|
|
|
|
I want to create a kind of active folder or a drive in such a way that when user selects it, instead of showing the files and folders inside it, it should load my dll or my com component. My dll should be able to provide the contents. I want to show some database collections and objects inside those collections.
This should be ingrated with the Windows file system so that whenever user selects the folder either from explorer or by any other means, my dll should be called. Also when user selects any other folder or file that is inside that folder, windows gives control to my dll with the name and properties of the selected object. My component should be able to take the appropriate action.
Thanks a ton
Nish
Nish
|
|
|
|
|
Just the fact that you're posting this question says you don't have the requisite knowledge to even start a project like this.
Ahhh! The wonders of the installable file system[^].
Forget writing this in C#. You'll be writing Interop code 'til your brains fall out.
|
|
|
|
|
You may be right but believe me Sir, I have achieved much more in my life. I never handled anything related to manipulating the file system. In this case too I will find the answer doesn't matter you help me or not. Thanks for the link.
Nish
nothing
|
|
|
|
|
If you are only looking to extend the Windows Explorer then you can check out Shell namespace extensions: here[^] and this commerical product[^].
Take care,
Tom
-----------------------------------------------
Check out my blog at http://tjoe.wordpress.com
|
|
|
|
|
In my code I create three combo boxes, and store them in an ArrayList. So:
myArrayList.Insert(0, new System.Windows.Forms.ComboBox());<br />
myArrayList.Insert(1, new System.Windows.Forms.ComboBox());<br />
myArrayList.Insert(2, new System.Windows.Forms.ComboBox());
I then add each of these comboboxes to my form; at the same time, I bind each of them to a shared data source and a shared event handler:
<br />
myForm.Controls.Add((ComboBox)myArrayList[0]);<br />
((ComboBox)myArrayList[0]).DataSource = aComparisonList_Strings;<br />
((ComboBox)myArrayList[0]).SelectedIndexChanged += new EventHandler(cmbComparison_SelectedIndexChanged);<br />
<br />
myForm.Controls.Add((ComboBox)myArrayList[1]);<br />
((ComboBox)myArrayList[1]).DataSource = aComparisonList_Strings;<br />
((ComboBox)myArrayList[1]).SelectedIndexChanged += new EventHandler(cmbComparison_SelectedIndexChanged);<br />
<br />
myForm.Controls.Add((ComboBox)myArrayList[2]);<br />
((ComboBox)myArrayList[2]).DataSource = aComparisonList_Strings;<br />
((ComboBox)myArrayList[2]).SelectedIndexChanged += new EventHandler(cmbComparison_SelectedIndexChanged);<br />
When the user chooses an item in the first combo box control, the SelectedIndex changes for ALL THREE CONTROLS. That's not what I want; I just want the three controls to share a datasource and an event handler. What am I doing wrong?
|
|
|
|
|
I don't think you will be able to share the data source like that. I believe datasources have a single "current record", which all the combo boxes are going to show. So if you change one, then the others will reflect that change also. This is typically the desired behavior.
What is the type of your data source? You may be able to Clone it to get around this problem.
Take care,
Tom
-----------------------------------------------
Check out my blog at http://tjoe.wordpress.com
|
|
|
|
|
Ah! Thank god I included the DataSource in the sample code, I didn't expect that to be the source of the problem. I would have never checked that.
The DataSource is an ArrayList with string to show in the drop down. It's not dynamic, so I can keep it anywhere, and it's short, so I can actually just generate it on the fly and assign it. That's inefficient, I know, and if I have 100 comboboxes, I'll have 100 arrays of the same 10 strings around, but I can live with that.
Let me go test your theory. Great catch, there.
|
|
|
|
|
Yep, that was it. I should have figured this out, since none of the other controls which were sharing handlers were showing similar behavior (buttons, checkboxes, etc), EXCEPT the other controls that had DataSources.
A couple of the comboboxes do have lengthy lists attached to them. You're saying I should CLONE my original array, and bind to that? Is that any more efficient that just looping through the original array, using combo.items.add to add it to each combo as I create it?
|
|
|
|
|
I'm not sure it matters. Any way you look at it, you will have to have three (assuming there are three ComboBoxes) lists. There are either three DataSources or three ComboBox.Items.
If the lists are long you may want to create a wrapper around the ArrayList. The wrapper would take a reference to an ArrayList. It would also implement the IList (and possibly the IList<T>) interface. Then you could just forward the IList method calls to the wrapped ArrayList. This way you have a small (in terms of memory) object that "points" to the large ArrayList. Then you would create three instances of your wrapper (all pointing to the same ArrayList). I believe this will get around the DataSource issue. This is really only useful if your ArrayList is large, since it would reduce memory usage.
Take care,
Tom
-----------------------------------------------
Check out my blog at http://tjoe.wordpress.com
|
|
|
|
|
Hi,
AFAIK you can share an array, ArrayList, List, ... between multiple ComboBoxes;
these collections don't have a "current selection" that they would impose on the ComboBoxes.
So I see no need to Clone() anything.
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
I'm not sure what you mean by "sharing" the Collection here. Aside from binding the Collection to the Combo as a DataSource (which I was doing earlier, and that was causing the problem), or copying the individual items from the Collection to the combo one at a time, what other method are you talking about to attach to the Collection to the combo?
|
|
|
|
|
Hi,
if you assign the same array/ArrayList/List as the DataSource of several ComboBoxes,
how would they exchange current selection info They don't!
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
I think the BindingContext[^] on the form maintains it for each DataSource. Since each ComboBox has the same data source (e.g. ReferenceEquals would return true), then they all share the same "current record" (which is maintained by the BindingContext. Apparently, you can "group" data bound controls using Panels (or GroupBox, etc) but you have to set the BindingContext property on the Panel to override the Form's BindingContext.
Take care,
Tom
-----------------------------------------------
Check out my blog at http://tjoe.wordpress.com
|
|
|
|
|
Well, Luc, try it out .
The whole point of binding DataSources is to share the Binding Context, so that all of the controls point at the same "record" in the DataSource. That way you can have several controls on the form (like, say, Back/Forward/Edit/Delete, etc) that all deal with the same "row" or data in the source.
I had completely forgotten about this when I used "combo.DataSource = myArray". I was just looking for a cheap way to make all of the items in my array show up in the combo box.
TJoe is right, if I want each combo to have its own context to the data in my array, I need to either Clone each array and bind to it, or just copy the items from the array to the combo.Items collection manually.
Since there is no real advantage to making the array a DataSource here (I'm not really using the BindingContext for what its intended), I'm just doing the latter now.
|
|
|
|