|
I think you need to call AcceptChanges before trying to update.
I rated this article 2 by mistake. It deserves more. I wanted to get to the second page... - vjedlicka 3:33 25 Nov '02
|
|
|
|
|
I tried, but still does not work! In this dataset there is a table that i need to update which has 4 fields. In appliction I change all fields, and when I call update method jus two fields are updated, but actally all fields in dataset are changed.
Anyway, AcceptChanges marks all modified rows as unchanged, and these rows update method does not take in count, isn't that?
|
|
|
|
|
Finally i found my problem, i had to use methos EndEdit() before updating dataset!! ))
|
|
|
|
|
Same problem i had over the weekend. I was gonna suggest checking the databinding then Textbox problem?
I rated this article 2 by mistake. It deserves more. I wanted to get to the second page... - vjedlicka 3:33 25 Nov '02
|
|
|
|
|
Anyone know of a good C# named pipe example?
Davy
Blog for Software Testing, Bugs, Quality, Security and Stability - www.latedecember.com
News From Angus, Scotland - The Angus Blog
|
|
|
|
|
I want to COPY a directory to another location NOT move it like the code below does.
Does anyone know of such a method call? I searched the help and didn't see anything. 
<br />
System.IO.Directory.Move(strSourceName, strDestination); <br />
|
|
|
|
|
MoveFile is in fact only renaming the directory, which is far less involved than duplicating the directory content (including all subdirectories as well).
There is no such Copy thing in the System.IO.Directory class. In fact, the only class that uses Win32Native.CopyFile (a native call, which is what you end up anyway) is the System.IO.File class. Means that you have to enumerate the files, and recursively call this method.
PS : The FCL is not guilty for not providing such method to us since even the native WIN32 ::CopyFile does not duplicate directories.
|
|
|
|
|
Thanks for the comments....BUT isn't it interesting that a user can do a CTRL+C and then a CTRL+V for paste to another directory? Would be nice to be able to do it in code. 
|
|
|
|
|
jesus4u wrote:
Would be nice to be able to do it in code.
You are 5 lines of code away from doing it. Please don't tell me it's challenging you. (and writing those lines takes probably even less than the sole time required to post on Cp).
|
|
|
|
|
What do you mean I am 5 lines of code away from doing it?
|
|
|
|
|
A simple question: how do I match # ?
Jonathan de Halleux.
|
|
|
|
|
Jonathan de Halleux wrote:
how do I match # ?
Same as any other non-reserved character, such as letters of the alphabet. The only time it needs to be escaped ("\#") is if you use the RegexOptions.IgnorePatternWhitespace flag.
Cheers
|
|
|
|
|
I want to create an windows form app that loads new forms into an existing area of a form. An example of this is windows explorer.
When you open win explorer, you get 2 pains divided by a splitter bar. If you click on a drive letter a new window opens in the second pained area, and so on...
How do I do this, is there an example that shows how, is there a term that covers this i can search on for examples?
Thanks
uboat42
|
|
|
|
|
Windows explorer is actually very simple in design... TreeView on the left, ListView on the right with a splitter in between.
To get the same thing in VS.NET, drop a TreeView on your form, set the DockStyle property to Left. Drop a splitter control on your form. Drop a ListView on your form and set DockStyle to Fill.
Now you just have to write the code to fill the tree and list views as well as handle the events 
Did I over-simplify it? 
James
"It is self repeating, of unknown pattern"
Data - Star Trek: The Next Generation
|
|
|
|
|
|
HAHAH, finally looked at the "empty" post long enough for the pic to load  Just couldnt figure it out. 
I rated this article 2 by mistake. It deserves more. I wanted to get to the second page... - vjedlicka 3:33 25 Nov '02
|
|
|
|
|
Is the part on the right of Windows Explorer exactly a ListView, or is it something derived from ListView? Does ListView inherently support the desktop-like qualities in Icon view where you can drag the icons around arbitrarily and make a cluttered mess?
This question leads into another question -- what is the best way to make a DesktopPanel-like control in C#. Something derived from Panel, ListView, or something entirely different?
|
|
|
|
|
Arun Bhalla wrote:
Is the part on the right of Windows Explorer exactly a ListView, or is it something derived from ListView?
It is a ListView, but I would assume it makes use of every single customization you could use
Arun Bhalla wrote:
Does ListView inherently support the desktop-like qualities in Icon view where you can drag the icons around arbitrarily and make a cluttered mess?
The underlying Win32 control does support it, but it doesn't look like the .NET wrapper of the control does. Of course, if you can do it in Win32 you can do it in .NET by using P/Invoke to call the system APIs. You just have a ton of work cut out for you if you are recreating all aspects of Explorer.
Arun Bhalla wrote:
what is the best way to make a DesktopPanel-like control in C#. Something derived from Panel, ListView, or something entirely different?
I'm not sure what type of program this would be mimicing...something like the Windows Taskbar (a screen wide/high form which stays docked to a side of the screen)? I'm pretty sure there is an article here on CP which makes something like this.
James
"It is self repeating, of unknown pattern"
Data - Star Trek: The Next Generation
|
|
|
|
|
James T. Johnson wrote:
un Bhalla wrote:
what is the best way to make a DesktopPanel-like control in C#. Something derived from Panel, ListView, or something entirely different?
I'm not sure what type of program this would be mimicing...something like the Windows Taskbar (a screen wide/high form which stays docked to a side of the screen)? I'm pretty sure there is an article here on CP which makes something like this.
Well, I think I was misleading with "DesktopPanel-like." I actually have in mind some control like (Java) Swing's JDesktopPane and an associated desktop manager. Ideally this control would manage scrolling, etc. I'm under the impression that a Panel (or ScrollablePanel) is my best bet, but I'm checking to see if there are other handy possibilities.
If one were to create a control in an application that mimics the system desktop or the iconic folder view of an Explorer, what would be the best route to take?
|
|
|
|
|
You may want to check out ActiveWare's layout manager (www.activewaresolutions.com). It will help manage your controls in a given area and automatically take care of the scrolling as well. I used it for a slightly different purpose, but it sounds like it may work here for you as well.
|
|
|
|
|
As James pointed out, the different views that can be created are just multiple controls in a single form.
If you have a more complex process (a window with data and a properties box) similar to VS, then you get into an MDI parent and child management scenario.
This requires that you first have a main form which is your container. You can use the Magic Library (www.dotnetmagic.com) to create a docked form which can act as a sliding property box. That property box is just a form with various list controls and an exposed public property so that you can pass what it should display properties on.
You have to decide how the children are opened....a selector window like the Solution Explorer or a menu option. The act of opening is just creating a new instance, setting its' MDIParent property to your main form, and showing it. The child forms are developed as normal stand-alone forms.
I also had a need for a child form to notify the parent form that a user performed a particular action. So I created an event and delegate in my child form and then delegated the event to a method in my parent form. My children just have to raise the event to get the logic in the parent fired off.
Now, this is definitely more complex -- and James' answer sounds more like what you're looking for. But this is the other way of managing a more complex type of display like Visual Studio.
_____________________________________________
The world is a dangerous place.
Not because of those that do evil,
but because of those who look on and do nothing.
|
|
|
|
|
Hello theRealCondor, James,
James thanks for your suggestions, I had pretty much worked on the principle of controls on the page layed out as you mentioned. I really wanted to take it to the next level.
theRealCondor, I think you hit it on the head. The sample picture at "www.dotnetmagic.com" of multiple windows and docking were exactly what what I wanted to achieve.
follow the link http://www.dotnetmagic.com/images3/features2.gif[^]
I would like to know more about this:
theRealCondor wrote:
I also had a need for a child form to notify the parent form that a user performed a particular action. So I created an event and delegate in my child form and then delegated the event to a method in my parent form. My children just have to raise the event to get the logic in the parent fired off.
It appears to me that to make multi windows play well I need to see how this works together.
Well thanks again for a place to start. Any additional help with this would be much appreciated.
Regards,
uBoat42
|
|
|
|
|
Situation:
I had an MDI parent. I added another form which is my 'launcher' and that is docked in the Magic Docking Control. In my parent -- at form load time -- it was a simple matter of a few simple steps:
Instantiate an instance of the dockManger
Instantiate an instance of the launcher (I pass the handle of
the parent to the launcher in the Constructor logic)
Add the launcher instance to the dockManager
Voila -- it works just grand and is very simple to implement
<br />
manager = new DockingManager(this, VisualStyle.IDE);<br />
Content ef = manager.Contents.Add(new editorForm<br />
(this, userChoices, desiredWeb), "Navigation Flows");<br />
ef.DisplaySize = new Size(192,464);<br />
ef.FloatingSize = new Size(192, 464);<br />
ef.AutoHideSize = new Size(192, 464);<br />
this.menuItem1.Enabled = true;<br />
manager.AddContentWithState(ef, State.DockLeft);<br />
Setting the sizes shown above is pixel tweaking to have the window open up as far as I wanted it to be displayed. (width is main value the manager is concerened with)
Next issue:
Each child constructs a navigation view. I was asked to change colors whenever one page in the view is replicated across children. This meant I had to wait until the child was fully implemented to handle the color change.
<br />
editView newView = new editView<br />
(StartingPageName, tcaAccessor, holdWebCollection, holdWebname);<br />
newView.MdiParent = thisParent;<br />
newView.Text = selectedObject.Text;<br />
main ParentForm = thisParent as main;<br />
newView.CompletedLoadEvent += new editView.CompletedLoadEventHandler(ParentForm.mdiParent_childLoadComplete);<br />
newView.Show();<br />
I pass the objects the child needs. I establish MDIParent to my parent form in the new child, and I establish the evenhandler in my parent form as well. Then I launch the child with the Show();
So in my base child form, I define the event:
<br />
public delegate void CompletedLoadEventHandler<br />
(object sender, string childName);<br />
public event CompletedLoadEventHandler CompletedLoadEvent;<br />
Then at the end of the load process I raise the event:
<br />
if (CompletedLoadEvent != null)<br />
CompletedLoadEvent(this, this.Text);<br />
You could code a number of custom events to comunicate back to the parent. I found that I had to do a custom event to guarantee that some accidental firing of an already-existing event did no occur.
If you happen to have the launcher as a menu item within the parent it is even easier since you do not have to hold reference to your parent inside the launcher. In setting up the launcher inside the manager --- creating the new launcher and passing (this) as a parameter which my launcher saves as a variable thisParent inside itself makes the launcher properly define the parent in each child.
_____________________________________________
The world is a dangerous place.
Not because of those that do evil,
but because of those who look on and do nothing.
|
|
|
|
|
Hello theRealCondor,
I managed to get so far with the frame of my mdi app using the magic control you pointed me to.
/* excuse's
Bear with me if you can, it's been a while between writing winforms apps. I've been doing a lot with web based stuff, so I'm trying to get my head around it again...
*/
I have 3 forms in my mdi app, frmMain (mdiparent), frmOutLookBar (_manager.DockLeft) and frmHome (should fill everything except the area of frmOutLookBar).
The idea is to have an outlook style layout. So I have the frmMain that loads the menu (frmOutLookBar), I dock this to the left. Here's where I've run into a wall. I can't figure out how to get the frmHome to fill the area to the right of the frmOutLookBar.
Code: 1st attempt;
<br />
_dockingManager = new DockingManager(this, VisualStyle.IDE);<br />
<br />
Content LeftWindow = _dockingManager.Contents.Add(new frmOutLookBar(), "Control Menu");<br />
<br />
_dockingManager.AddContentWithState(LeftWindow, State.DockLeft);<br />
_dockingManager.ShowContent(LeftWindow);<br />
This gave me the stand alone left docking as hoped. I also tried to dock the frmHome to the right.
Code: 2nd attempt;
<br />
_dockingManager = new DockingManager(this, VisualStyle.IDE);<br />
<br />
Content LeftWindow = _dockingManager.Contents.Add(new frmOutLookBar(), "Control Menu");<br />
<br />
_dockingManager.AddContentWithState(LeftWindow, State.DockLeft);<br />
_dockingManager.ShowContent(LeftWindow);<br />
<br />
Content RightWindow = _dockingManager.Contents.Add(new frmHome(), "Control Menu");<br />
<br />
_dockingManager.AddContentWithState(RightWindow, State.DockRight);<br />
_dockingManager.ShowContent(RightWindow);<br />
This gave me two docked windows, a left docked window, a gap and a right docked window??
Any help with getting frmHome on the right side as a filler would be great!
Definitely getting closer to what I'm after,
John
|
|
|
|
|
Sorry it took too long to reply....my father died last weekend.
Do this:
Your work with docking the control on the left is fine.
Make certain that your frmHome Dock = Fill.
frmHome fillscrn = new frmHome();
fillscrn.MDIParent = this;
fillscrn.Show();
Now what this gives you is your Outlook style on the left which slides in and out. A second window on the right that fills the area. It's code functions independant which is fine as long as your main form has no need for catching events from the child.
If you want a TRUE outlook experience, then you can take an easier approach:
mainForm is your only form.
Drop in a panel and create your OutlookPanel inside this panel (Dock=Left).
Drop a slider in the form.
Drop another panel in the form Dock=Fill
Populate the panel with all your data.
This gives you a true Outlook experience but it is a fairly static form. With the MDIChild approach you gain a benefit if you are showing a different form for different users -- since you can encapsulate your logic within each individual form.
Another benefit of the MDIChild approach is that the panel (your right-filled form) is coded as a stand-alone form which contains all of its' logic in one place and is not scattered among the icon bar logic and other form management tasks.
If the child form needs to be notified that an icon was clicked in the Outlook bar, then you expose those via events (full detail is in the MSDN help files within VS)
Hope this moves you forward. 
_____________________________________________
The world is a dangerous place.
Not because of those that do evil,
but because of those who look on and do nothing.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
