C# Discussion Boards - CodeProject

Re: Receiving Input from other processes/OS (aka Standard In)

23-Sep-03 5:55

The System.Diagnostics namespace is here to help! Smile | :)

There is a class called Process. It allows you to use a ProcessStartInfo struct that lets you use the ShellExecuteEx API from Windows that will execute the app (or whatever is the handler) for a file extension, MIME type, etc. Basically, create a new Process object, create a new ProcessStartInfo, fill in the info in the struct and set ProcessStartpInfo.ShellExecute = true, and call Start on the Process instance with the ProcessStartInfo.

Before doing so, the Process class also defines properties for getting a StreamReader for all your standard I/O.

The documentation for the Process class has a lot of good information and examples for everything you're needing to do.

-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----

Blake Coverett23-Sep-03 6:51

Blake Coverett

23-Sep-03 6:51

Heath:

I believe you misread the point of his question.

AJB:

If your app is associated with a file extension you will be called with the name of that file as a command line argument, i.e. the args in static int Main(string[] args), not the stream on standard input.

And file types registrations are stored, unsurprisingly, in the registry. Whatever tool you use to create a install package will have that as an easy option. If you want to do it manually use the Microsoft.Win32.Registry class and read the documentation on shell file types here.

I can no longer find an MSDN reference to the IE mime handler information, but by memory, HKCR/MIME/database/Content Type/{insert your mime type here}/Extension = {make sure it points to the extention you've mapped above}

You can also do fancier things with Monikers and DocObjects, but that would be hard to do with C#.

--
-Blake (com/bcdev/blake)

Re: Receiving Input from other processes/OS (aka Standard In)

AJB...23-Sep-03 7:20

AJB...

23-Sep-03 7:20

Thanks to both of you for your response. You both are correct and this info has been helpful except I still don't have enough info. I am aware of reading the file path from the Main method's args but it still doesn't get me where I want to be to deal with the case where I already have a process for my app running (and I only want to allow one process running for this app). The basic logic I want is this:

Main()
check to see if a process for my app is already running (I know how to do this)
if a process exists, send the args to it
else continue running and start my app normally by continuing execution of my main method

From Heath's response and reading the documentation (which is weak on this) it seems that I would have to have my main method start a new Process for my app if its not already running because I need to redirect the standard input. Is that true? And how does the subsequent running of my app, after it finds the already running process, send that info to the process?

Thanks

Re: Receiving Input from other processes/OS (aka Standard In)

Blake Coverett23-Sep-03 8:05

Blake Coverett

23-Sep-03 8:05

AJB... wrote:
From Heath's response and reading the documentation (which is weak on this) it seems that I would have to have my main method start a new Process for my app if its not already running because I need to redirect the standard input. Is that true? And how does the subsequent running of my app, after it finds the already running process, send that info to the process

No, Heath's response is certainly correct, but it is not the correct tool for the problem you are describing. You can not use the Process.ShellExecute or ProcessStartInfo to pass information to an already running process. (Well, not without implementing Shell DDE, which is old, icky and hard to do in C#.)

You can also not pass something as standard input to an already running process.

What you've described already knowing how to do is the correct first step. It sounds like the only part you are missing is how to send the arguments to the already running process if you discover there is one. This is a basic interprocess communication problem and there are many perfectly good solutions. Your main process should listen via .NET remoting or a socket or even just a custom windows message, for filename's to be passed to it. It's hard to recommend which of the many options here to use without knowing more about your application.

Some more advanced things to keep in mind:

~ What happens if a second file of the type you care about is opened while your main process is still handling the previous one?

~ How fast is your main process to load? Should you consider a small stub that actually gets registered to handle the file type and passes the name on to your main worker process?

~ Do you need to process streams as they download in IE, or just get passed the completely downloaded file out of the cache? If so you need to look at URL monikers.

--
-Blake (com/bcdev/blake)

Re: Receiving Input from other processes/OS (aka Standard In)

Heath Stewart23-Sep-03 8:47

23-Sep-03 8:47

Ah, I see he posted what he emailed me directly here.

I must've missed that running instance part otherwise I wouldn't have posted that.

What I did mention, however, is that you can use either DDE, but like you said - that's a bit tricky.

Coming from a COM background, I usually prefer the ROT (running object table) for doing this. There is some support in .NET's BCL for this, but you still have to implement various things to make it work. With a document architecture, you could associate a progid with the document type (file extension, for one example) and get an instance of the document type from the ROT. If the document type has a property to get the running app instance, you could then get the instance and load the new doc into the app instance. This means, then, that you have to insert objects into the ROT. There isn't support for this in .NET, but it's not hard to P/Invoke. This is a very simplistic way of doing things (really, it's better to deal with monikers, in which case you could use a simple file moniker) but it requires a pretty good understanding of COM.

It's all about how much you want to write and how much you want to support. If you do use monikers and the ROT, your document app could easily be invoked from COM. With a little extra work, you could implement an out-of-process server, similar to how the Office apps work.

Just my $0.02.

Newbie in C#

Member 59611223-Sep-03 4:42

Member 596112

23-Sep-03 4:42

Hi,

I would like to learn C# and particulary write an MFC like application in C# :

I need :

- a mainframe with menu, toolbar and status bar
- some documents with associated views (like MFC)

Is it possible in C# to write this kind of application ?
All demo programs I found has a single window (eventually some popup dialog), but never I seen a multi-document C# demo.
Could you give me a start point (example) or doc for this kind of application ?

Thanks in advance,

Re: Newbie in C#

Heath Stewart23-Sep-03 6:02

System.UnauthorizedAccessException

23-Sep-03 6:02

The main frame is no problem. Create a new Windows Forms project and drag a menu and toolbar on it.

The doc/view architecture - something MFC was partly designed for - is a bit trickier but not impossible - heck, nothing is impossible given time. There are several articles on CP that I've seen regarding this topic (like using MDI windows which .NET provides built-in support for) that would be worth checking out. In all, though, keep in mind that all .NET apps (because they all compile down to IL, so the source language matters little) have access to everything MFC does (Win32 APIs). Some things are harder, some things are easier.

Also, you'll probably want to dig through the .NET Framework SDK docs - especially the System.Windows.Forms namespace - to see what's available. The docs also include several articles about Windows Forms and some on MSDN that even approach them from an MFC developer's viewpoint. It's always good to know the depth and temperature of the pool (and any creatures that might be lurking in it) before jumping in. Smile | :)

Re: Newbie in C#

Michael P Butler23-Sep-03 6:44

Michael P Butler

23-Sep-03 6:44

Have a look at Genghis[^] and its sample application.

Michael

'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879

ich_bins23-Sep-03 4:29

ich_bins

23-Sep-03 4:29

I get this exception when my application wants to delete a file.

the programm load a dll-file from a server and writes the stream into a file with this code:

HttpWebRequest wr =(HttpWebRequest)WebRequest.Create<br />
                   ("http://localhost/Server/Tools/"+strFileName);<br />
HttpWebResponse ws = (HttpWebResponse)wr.GetResponse();<br />
Stream str = ws.GetResponseStream();<br />
...<br />
FileStream fstr = new FileStream(strFileName, FileMode.Create,FileAccess.Write);<br />
fstr.Write(inBuf, 0, bytesRead);<br />
str.Close();<br />
fstr.Close();

but when I start this function a second time (and the session is also running), I get the exception.

so what can I do? how can I stopp using the dll-file to delete it?

Control Designer & Child Controls Issue

scott@otech.com23-Sep-03 4:14

23-Sep-03 4:14

Does anyone have a solution to this problem:

When implementing a ControlDesigner or ParentControlDesigner, if one has a
UserControl that contains child controls as follows:

+========UserControl=========+
| +-----------------------------------+ |
| | Caption Panel | |
| +-----------------------------------+ |
| +---------------------------------- + |
| | Content Panel | |
| +-----------------------------------+ |
+=========================+

My desire is to have ToolboxItems that are added to the UserControl at
design-time be added as children of the ContentPanel.

- Using a ControlDesigner and invoking CreateComponent() adds the control to
the current design document (the UserControl).
- If one attempts to "re-parent" the control being "dropped" within the
designer for the UserControl by doing the following

Control target = ((myUserControl)this.Control).ContentPanel;
// the (child) Control where the dropped control should be moved-to

this.Control.Controls.RemoveAt(this.Control.Controls.IndexOf(ctl));
// remove the control from the UserControl (top-level parent)

ctl.Parent = target;
// assign the .Parent property of the control

target.Controls.Add(ctl);
// add the dropped control to the ContentPanel Controls collection

The error "Object reference not set to an instance of an object" occurs.

Do I need to create a(nother) designer for the ContentPanel so that IT can
serve as the target of the DragDrop? Is there some other (more expedient)
way to do this? Initiate an additional DesignerTransaction that makes the
re-parenting change? Making the .Parent and Controls[] change, and then
using the ComponentChangeService to make Changing/Changed notifications on
the "Parent" and "Controls" PropertyDescriptors ?

Heath Stewart23-Sep-03 5:50

23-Sep-03 5:50

There are ways that you can capture the original parenting the parent it on your user control in the first place. It's been a while since I worked with the designer stuff, but there is a myriad of interfaces (such as and virtual methods (such as overriding OnDropDrop) and properties I've seen that can help you do this. You could also, for instance, use GetService to get the IComponentChangeService service interface, then handle the ComponentAdding event to determine when a component is about to be added, and add it yourself and ignore the drop. Just a thought.

Also, where is the exception being thrown, exactly? That might give us some better idea of what your current problem is.

scott@otech.com23-Sep-03 6:20

23-Sep-03 6:20

Well actually this isn't my exact problem. Smile | :)

I didn't feel like typing a whole big mess so I just copied this problem from someone else's post on another site because what he is trying to accomplish is the same as what I'm trying to accomplish:

Allowing a control added to a user control in the designer to really be parented to a child control of that user control whether it be added through a custom verb event, or dropped onto the control...

In my designer for the top level parent I've got some code like this to add a new control to the parent control in response to the use of a custom verb:

<br />
Private Sub OnAddButton(ByVal sender As Object, ByVal e As EventArgs)<br />
            Dim b As XPanderLinkLabel<br />
            Dim h As IDesignerHost = DirectCast(GetService(GetType(IDesignerHost)), IDesignerHost)<br />
            Dim dt As DesignerTransaction<br />
            Dim c As IComponentChangeService = DirectCast(getservice(GetType(IComponentChangeService)), IComponentChangeService)<br />
<br />
            'Add a new button to the collection<br />
            dt = h.CreateTransaction("Add Link")<br />
            c.OnComponentChanging(m_XPander, Nothing)<br />
            b = DirectCast(h.CreateComponent(GetType(XPanderLinkLabel)), XPanderLinkLabel)<br />
            m_XPander.contentpanel.controls.add(b)<br />
            c.OnComponentChanged(m_XPander, Nothing, Nothing, Nothing)<br />
            dt.Commit()<br />
        End Sub<br />

And then in the parent control I handle the OnControlAdded event of the internal panel that I want to be the "true parent"

<br />
        Private Sub pnlLinks_ControlAdded(ByVal sender As Object, ByVal e As System.Windows.Forms.ControlEventArgs) Handles pnlLinks.ControlAdded<br />
        If TypeOf (e.Control) Is XPanderLinkLabel Then<br />
                Me.Links.Add(DirectCast(e.Control, XPanderLinkLabel))<br />
                DirectCast(e.Control, XPanderLinkLabel).ImageList = Me.ImageList<br />
                e.Control.Dock = DockStyle.Top<br />
                Invalidate()<br />
            End If<br />
        End Sub<br />

This was the first approach that I tried and it did not work because the code was never output. I would get this error at compile time:

".net Code generation for property 'Controls' failed. Error was: 'Object reference not set to an instance of an object."

Essentially I don't care how I can accomplish it, I just want to somehow be able to have the control dropped on the parent control or added through a custom verb to really be parented to the internal control.

Heath Stewart23-Sep-03 6:47

23-Sep-03 6:47

The code you have looks like it might work, but it would be nice to know on which line the exception is being thrown.

Also, the various ideas I gave you should work. I've done similar things to what you're needing before without problems. It's essentially the same concept as what you're doing now, but it uses the design interfaces and properties.

The problem you might be running into is that you're relying on mostly runtime code. While this sometimes works, the code serializer (what actually serializes the design-time code to the source file) might be having problems detecting your changes or giving you instances of what you expect. If you stick with the design interfaces and properties, this shouldn't be a problem (hopefully Smile | :)

scott@otech.com24-Sep-03 7:51

24-Sep-03 7:51

I've tried some more things and still have not had any luck getting this to work... Do you by chance have any sample code form the times you've done similar things that might serve as a good example?

Heath Stewart24-Sep-03 8:50

24-Sep-03 8:50

No, not anymore.

Did you try getting the IComponentChangeService and overriding how controls are added? There are also virtual methods on the designer classes that allow you to do this. They get called when a component is added. In your designer, override one of these methods and re-site the component. This doesn't rely on runtime code which could be the problem.

scott@otech.com24-Sep-03 9:02

24-Sep-03 9:02

I've tried that. This is the code I've got. Perhaps I'm doing something wrong...

<br />
  Public NotInheritable Class XPanderDesigner<br />
        Inherits System.Windows.Forms.Design.ParentControlDesigner<br />
<br />
        Private m_BorderPen As New Pen(Color.FromKnownColor(KnownColor.ControlDarkDark))<br />
        Private m_XPander As XPander<br />
        Private WithEvents m_ICCService As IComponentChangeService<br />
<br />
        Public Sub New()<br />
            m_BorderPen.DashStyle = Drawing.Drawing2D.DashStyle.Dash<br />
        End Sub<br />
<br />
        Public Overrides Sub Initialize(ByVal component As System.ComponentModel.IComponent)<br />
            MyBase.Initialize(component)<br />
            m_XPander = CType(Me.Control, XPander)<br />
        End Sub<br />
<br />
        Protected Overrides Sub OnPaintAdornments(ByVal pe As PaintEventArgs)<br />
            MyBase.OnPaintAdornments(pe)<br />
            pe.Graphics.DrawRectangle(m_BorderPen, 0, 0, m_XPander.Width - 2, m_XPander.Height - 2)<br />
<br />
        End Sub<br />
<br />
        Private Sub m_ICCSerivce_ComponentAdding(ByVal sender As Object, ByVal e As System.ComponentModel.Design.ComponentEventArgs) Handles m_ICCService.ComponentAdding<br />
            Dim b As XPanderLinkLabel<br />
<br />
            '            If TypeOf (e.Component) Is XPanderLinkLabel Then<br />
            m_ICCService.OnComponentChanging(m_XPander, Nothing)<br />
            m_ICCService.OnComponentChanging(m_XPander.pnlLinks, Nothing)<br />
            e.Component.Site = CType(m_XPander.pnlLinks, ISite)<br />
            m_XPander.pnlLinks.Controls.Add(DirectCast(e.Component, XPanderLinkLabel))<br />
            m_ICCService.OnComponentChanged(m_XPander.pnlLinks, Nothing, Nothing, Nothing)<br />
            m_ICCService.OnComponentChanged(m_XPander, Nothing, Nothing, Nothing)<br />
<br />
            '           End If<br />
        End Sub<br />
    End Class<br />

pnlLinks is the internal child control of the main user control m_Xpander that I want to be the true parent of the controls dropped onto the XPander. When I drag & drop in designmode with this code it parents the controls to the XPander, and not the internal panel of the xpander.

copy constructor needed?

berndg23-Sep-03 2:59

berndg

23-Sep-03 2:59

Recent convert from C++. Coding in C#, do I need defining copy constructors?

The documentation to Object.MemberwiseClone() suggests the answer is No, but I'd be grateful for confirmation or correction.

TIA,
Bernd

Heath Stewart23-Sep-03 3:12

23-Sep-03 3:12

Short answer: it depends.

First, there's nothing wrong with copy constructors. It's not commonly done in .NET because other, more common facilities exist (like implementing the ICloneable interface). This way, you can simply do MyObj o2 = (MyObj)o1.Clone(); (depending on whether you use a implicit or explicit interface declaration - something new to .NET). In your implementation of ICloneable.Clone, then, you can decide how to clone one object to another however you want.

Object.MemberwiseClone(), however, does a shallow copy. What this means is that all intrinsic types (int, long, bool, etc.) are copied while all reference types (almost everything else) are merely referenced by the new object and, if you change a reference type in one object it will be changed in the other. A collection is a good example: if o1 has a collection and you use Object.MemberwiseClone, then o2 will have a reference to the same collection. If you add or remove a member of that collection in either object, it will be reflected in the other because it is the same collection. If you set the collection member to null in one object, however, the other object will still hold on to a reference of it, so if you use this approach, be sure to clean everything up properly.

So, it really depends on your needs. Do you want the cloned object to have a shallow copy (i.e., a reference) of objects or a deep copy (i.e., completely different copy) where everything is a completely different object? If so, I would recommend implementing the ICloneable interface for consistency and better support, but there's nothing wrong with using a copy constructor - heck, if you want, do both! Just make use of the copy constructor in your implementation of ICloneable.

Alvaro Mendez23-Sep-03 4:43

Alvaro Mendez

23-Sep-03 4:43

Great answer Heath (got my 5).

Now, comparing these 2 lines:

MyObj o2 = (MyObj)o1.Clone(); 
MyObj o2 = new MyObj(o1);

Syntactically I'd prefer to use the second line (with the copy ctor) to copy the object. It seems clearer -- you're creating a new object based on another one.

So I ask, why bother with implementing ICloneable and overriding Clone and then having to cast the result? I guess I just don't understand what you mean by "consistency and better support" as the benefits. Do you have specific cases where implementing ICloneable is expected/required, such as for a collection class?

Thanks,
Alvaro

Hey! It compiles! Ship it.

Heath Stewart23-Sep-03 5:39

23-Sep-03 5:39

There's nothing wrong with either method, I just prefer implementing ICloneable because it's consistent with everything else in .NET and "Microsoft's way of doing things". Poke tongue | ;-P

You can actually eliminate the need for a cast by having your own Clone() method and implementing ICloneable explicitly:

public class MyClass : ICloneable
{
  // ...
  public MyClass Clone()
  {
    // Create the clone and return.
  }
  object ICloneable.Clone()
  {
    return this.Clone();
  }
}

Explicit interfaces are great in many cases, especially when you have to define a method that is defined in an interface already, or implementing two or more interfaces that may have the same members. They also come in handy for typed expressions like above. Several of your ICollection implementations in the BCL do this very thing to, at the very least, give you the appearance of a typed return and to prevent you from having to cast.

As I said, though, you could use both ways::

public class MyClass : ICloneable
{
  // ...
  public MyClass(MyClass orig)
  {
    // Create this clone from the original.
  }
  public MyClass Clone()
  {
    return new MyClass(this);
  }
  object ICloneable.Clone()
  {
    return this.Clone();
  }
}

You get the best of both worlds, then.

Another reason, which I use in a complex and abstract tree "framework" in the app I architected for work, is for treating object instances depending on what they implement. While recursing through a tree during various operations (such as cloning a tree) I determine if the object (so remember, I have no idea if a copy constructor exists for the Type without using quite a bit of reflection and many extra calls) implements ICloneable. If it does, I clone it. If it doesn't, I use a tab bit of reflection to create a new instance and do a memberwise clone (shallow copy). Most of the objects in the tree implement ICloneable, so I don't revert to reflection often and will most likely remove that functionality in a future version. The tree objects facilitate cloning by checking certain member fields for cloneability and do things in a similar matter. This creates a large chunck of functionality that never has to deal with any specific types in either the base class or the various child classes for a very nice OO design.

This is just one example where using the interface helps, but it's not required. It just depends on circumstances (checking for a copy constructor for the conditions above would be more expensive) and personal preferences (like I said, I like to remain consistent with most aspects of whatever API/framework I'm writing with/for).

Because it is so easy to do (see the second code example above), I would recommend doing both the copy ctor and implement ICloneable if you do, indeed, want to include a copy ctor. The extra IL would be trivial / negligable and it would allow for better flexibility.

Alvaro Mendez23-Sep-03 10:37

Alvaro Mendez

23-Sep-03 10:37

I'm a little alarmed about your ICloneable.Clone implementation. It just calls Clone, which would seem to indicate an endless recursive call to itself. Does putting this. in front of it tell the compiler to call the other version?

So if I have,

MyClass m1 = new MyClass();
 
m1.Clone();                        // 1
object o = m1.Clone();             // 2
MyClass m2 = (MyClass)m1.Clone();  // 3

What does each call to Clone actually end up calling?

Thanks,
Alvaro

Hey! It compiles! Ship it.

Heath Stewart23-Sep-03 10:47

23-Sep-03 10:47

First of all, I always type the implicit this. to help distinguish what's an instance member and what's a variable, just like I type the class name even for static members. It's basically just a way I manage my code. It makes absolutely NO difference when it compiles. The IL instructions are the same in either case.

Second, the seemingly self-recursive cloning: doesn't happen. Are you familiar with explicit interface implementations? Notice how I used the interface name in the last Clone method: object ICloneable.Clone()? That means that you must cast the object (or define the object reference as that interface) in order to call that particular method. In the explicit interface implementation, I called this.Clone(); which is the Clone method of my class. If I did ((ICloneable)this).Clone(), then that would definitely be a problem! That is not what I did, however. Trust me, it works.

Try throwing together a quick class that does this. Compile it and examine the IL (don't decompile - the IL is what you want to look at for this): it should show you what's being done.

You don't necessarily have to implement ICloneable as an explicit interface. I only did it because someone (might have been you - don't remember) complained that you have to cast the return value of Clone. By having another Clone method on your class that returns the proper type, you won't have to worry about it. Heck, you don't even need to implement ICloneable, but that may throw-off developers that are thinking that you implement ICloneable when, in fact, you don't (and they didn't read your documentation, which happens far too often than not).

Alvaro Mendez23-Sep-03 11:01

Alvaro Mendez

23-Sep-03 11:01

Thanks for the explanation. "Explicit interface implementation" is definitely cool. Cool | :cool:

Heath Stewart wrote:
First of all, I always type the implicit this. to help distinguish what's an instance member and what's a variable, just like I type the class name even for static members.

Yes, I do the same for instance fields (well, in Java anyway; in .NET I use the m_ prefix for my fields.) But for instance methods I think this. is just overkill. Since global methods do not exist, it's clear that calling a method directly (without a something. in front it) means you're calling a member of the class.

Regards,
Alvaro

Hey! It compiles! Ship it.

Heath Stewart23-Sep-03 13:04