C# Discussion Boards - CodeProject

led mike9-Oct-08 4:40

led mike

9-Oct-08 4:40

Laji59 wrote:
If you know we have a thing that is named Accelerator in Visual C++ for working with shortcut and keyboard
do we have any things like this in C#.

Are you kidding? [^] Roll eyes | :rolleyes:

Good luck, you're going to need it.

led mike

Pedram Behroozi9-Oct-08 4:43

Pedram Behroozi

9-Oct-08 4:43

Well, I don't no anything about Accelerator! What do you want to do In C#?

While (true) { Human.isLearnable = true; }

Laji599-Oct-08 5:38

Laji59

9-Oct-08 5:38

I want to manage some Keys like "Alt+F4" ( for example for exit)
but I don`t want use "KeyDown" event of controls
can I do it in any way ?

Hello Friends

DaveyM699-Oct-08 8:53

DaveyM69

9-Oct-08 8:53

If this is WinForms, set the form's KeyPreview property to true and handle the form's various key events.

Dave
BTW, 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)

Re: COM Interface Question

Pedram Behroozi9-Oct-08 22:38

Pedram Behroozi

9-Oct-08 22:38

When you turn on KeyPreview, you can manage all events occurring by keyboard in Form_KeyDown:

private void Form1_KeyDown(object sender, KeyEventArgs e)
{
    if (e.Modifiers == Keys.Alt && e.KeyCode == Keys.Q)
        Application.Exit(); // It works when KeyPreview is true.
}

While (true) { Human.isLearnable = true; }

COM Interface Question

MSBassSinger9-Oct-08 4:30

MSBassSinger

9-Oct-08 4:30

I have a VB6 DLL that has a class, ICommonEnv, that is used as an interface definition for another VB6 class, clsCommonEnv, that implements ICommonEnv. When I build the VB6 DLL, in the VS2005 Object viewer I see clsCommonEnv, _clsCommonEnv, __clsCommonEnv, clsCommonEnvClass, ICommonEnv,
_ICommonEnv, and __ICommonEnv. I understand that the "_" is VB6's class interface and "__" is VB6's events inerface.

I want to use an instance of clsCommonEnv in my C# app, and, of course, I referenced the COM DLL and added the "using" statement in my .cs file.

I have not found any documentation that tells me when and where to use which of the interfaces and classes. For example, I also pass this object to C# and other VB6 objects that expect the ICommonEnv interface. I have tried this code by trial and error, but I would like to find some documentation that really explains what to use and why.

For example...

//C# Usage
private _ICommonEnv m_oCommonEnvCOM;

m_oCommonEnvCOM = new clsCommonEnvClass();

// Later I pass this to a VB6 object method that expects the ICommonEnv interface
// VB6 method signature:
// Public Function Init(ByRef oCommonEnv As ICommonEnv) As Long

Int32 lRet = someVB6COMObject.Init(ref m_oCommonEnvCOM)

Thanks in advance for those who can help point me to useful documentation.

led mike9-Oct-08 4:38

led mike

9-Oct-08 4:38

MSBassSinger wrote:
Thanks in advance for those who can help point me to useful documentation.

Introduction to COM interop[^]

led mike

Re: VB6 COM Interface Question

MSBassSinger9-Oct-08 6:17

MSBassSinger

9-Oct-08 6:17

I appreciate the quick response. The article covers stuff I've read before, and doesn't address the peculiar aspects of VB6 COM objects in C# (or .NET in general). Unfortunately, I've inherited production code that has the poor design of using ICommonEnv as an "interface class" in VB6 from which the clsCommonEnv class implements that interface. Good VB6 OO design is making the clsCommonEnv class (and no ICommonEnv class whatsoever), then having any other classes implement that interface (Implements clsCommonEnv instead of Implements ICommonEnv).

An article like the one you posted that is geared to VB6 COM DLLs, rather than C++ COM DLLs is what I am looking for.

Thanks, again, though for being kind enough to post a quick response.

Re: VB6 COM Interface Question

Paul Conrad9-Oct-08 7:08

Paul Conrad

9-Oct-08 7:08

MSBassSinger wrote:
rather than C++ COM DLLs is what I am looking for

Really? In your original post, you wrote:

When I build the VB6 DLL

Which is it, C++ or VB?

"The clue train passed his station without stopping." - John Simmons / outlaw programmer

"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon

"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham

Re: VB6 COM Interface Question

MSBassSinger9-Oct-08 7:54

MSBassSinger

9-Oct-08 7:54

As I have said in both posts, VB6 DLLs. I never said I was looking for C++ COM info. The 1st response was about C++ DLLs, which is not the issue in my case.

The full line, of which you quoted a part, is:

An article like the one you posted that is geared to VB6 COM DLLs, rather than C++ COM DLLs is what I am looking for.

The object of "what I am looking for" is clearly "article like the one you posted that is geared to VB6 COM DLLs". I should have placed an apostrophe after the phrase "rather than C++ COM DLLs".

All these event handlers

Dewald9-Oct-08 3:56

9-Oct-08 3:56

I think my code has just raised a OnGenerateHeadache() event Smile | :)

I'm implementing a TCP server that accepts client connections and process messages sent to it, then sends an appropriate response. Something gave me the idea that using events and delegates was a good idea but now I'm starting to wonder if it was. My code works and I will probably not change it (unless I can improve it) but I'd like to get the opinion of experts on how sound my approach is.

What got me thinking along the lines of events and delegates at first is this; data coming in over a TCP connection could come in various bursts. It's just a stream of data and the start and end of one message might not arrive in the same burst. So my TCPConnection class raises an event every time it receives data but it won't know whether that data constitutes a complete message or just the first half of a message. It simply raises an event (called DataReceived(byte[] stream)), passing the bytes received as a parameter. Whoever handles that event is responsible for checking when the message is complete.

Enters my next class, FramingEngine. My way of establishing when a message is complete is to 'frame' it with extra bytes before and after. My protocol is slightly more complex but for the sake of simplicity let's just say it works as follows. Every message will start with a 0x02 byte and end with a 0x03 byte (unless the byte is preceded by a 0x10 byte in which case it is just part of the message).

So FramingEngine has a method called DecodeIncomingData(byte[] buffer) which checks for these bytes and packs the message into an internal buffer until it receives the terminating bytes of a message. At this point the method knows that it has received a complete message and it raises an event (called MessageReceived(byte[] message)), passing the internal buffer which is stripped of all these control bytes.

Enters my next class, MessagingEngine. This is the class that understands the messages. In other words, this class is specific to my current project while TCPConnection and FramingEngine are common classes that could be used in any other project of mine that also utilizes TCP comms. So MessagingEngine has a method called HandleMessage(byte[] message) which processes a message, decides what to do with it and responds if necessary.

So basically, data coming in on the TCP connection gets passed all the way down to MessagingEngine through events. Something like this:

TCPConnection myConnection; //This is instantiated earlier, don't worry about how it's done.

FramingEngine frameEngine = new FramingEngine();
MessagingEngine messageEngine = new MessagingEngine();

myConnection.DataReceived += new TCPConnection.DataReceivedDelegate(frameEngine.DecodeIncomingData);
frameEngine.MessageReceived += new FramingEngine.FrameReceivedDelegate(messageEngine.HandleMessage);

So far so good, but now, to some of the messages (most of them actually) that MessagingEngine receives it has to respond, but is has to do so framing the responses through FramingEngine first and then ultimately sending it to TCPConnection.

The problem is that MessagingEngine has no knowledge of the TCP connection on which the data was received (and is to be sent again). It doesn't even have knowledge of FramingEngine. So, I decided to employ this mechanism of events being raised and handled to pass the message up the chain of abstraction again. As I said, it works, but I'm not sure this is good programming. What are your opinions?

So MessagingEngine when it's ready to respond, raises an event called SendMessage(byte[] message). FramingEngine has a method called EncodeOutgoingData(byte[] message) which is used to handle the event raised by MessagingEngine. In turn, EncodeOutgoingData raises an event called MessageFramed(byte[] buffer) which is handled by the TCP connection's SendData(byte[] buffer) method, like so:

messageEngine.SendMessage += new MessagingEngine.SendMessageDelegate(frameEngine.EncodeOutgoingData);
frameEngine.MessageFramed += new FramingEngine.MessageFramedDelegate(myConnection.SendData)

Would you have done it differently? Which is an elegant way of doing this?

DaveyM699-Oct-08 4:43

DaveyM69

9-Oct-08 4:43

Sounds good to me - if it works, then cool Cool | :cool:

It may be doable without events unless there are other objects that need to be notified about events in your chain.

Have I got this right?
TCPConnection knows about FramingEngine.
FramingEngine knows about MessagingEngine.

If so,
TCPConnection could call a method in FramingEngine.
FramingEngine could call a method in MessagingEngine.

MessagingEngine could send data back to FramingEngine via a delegate.
FramingEngine could send data back to TCPConnection via a delegate.

Dave
BTW, 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)

Dewald9-Oct-08 5:11

9-Oct-08 5:11

DaveyM69 wrote:
Have I got this right?
TCPConnection knows about FramingEngine.
FramingEngine knows about MessagingEngine.

Not really no. At least not in my current implementation. I wanted to maintain strict abstraction between these classes so that, in future, I could still replace any of the classes without having to make changes to the other classes. Say for instance I decide to employ a whole new and different type of framing, I could just replace the FramingEngine with something new and not have to worry about TCPConnection or MessagingEngine breaking.

Also, let's say I'm not using TCP comms anymore but some direct serial cable link or whatever. I simply have to write a new class called SerialConnection which can still pass messages down through FramingEngine to MessagingEngine etc.

I could even decide to drop FramingEngine altogether and couple TCPConnection and MessagingEngine directly without having to make changes to either.

DaveyM69 wrote:
If so,
TCPConnection could call a method in FramingEngine.
FramingEngine could call a method in MessagingEngine.

I'm starting to think that this would indeed have been a better approach, obviously losing the freedom I just described above but what the heck. I doubt it's THAT important anyway.

led mike9-Oct-08 4:47

led mike

9-Oct-08 4:47

Dewald wrote:
So, I decided to employ this mechanism of events being raised and handled to pass the message up the chain of abstraction again. As I said, it works, but I'm not sure this is good programming. What are your opinions?

Yeah that seems a bit off. Perhaps something far simpler ( KISS[^] ), like associating the Socket to the Message until it is determined that no reply is required, otherwise the socket is then used to send the reply.

led mike

S. Senthil Kumar9-Oct-08 5:00

S. Senthil Kumar

9-Oct-08 5:00

The event mechanism looks ok for the receiving part, but it looks a bit awkard for the sending part. Usually, people think of events as things that are optional i.e., you can subscribe if you're interested. People also implicitly associate it with multiple listeners. All of which fit in nicely when receiving data - multiple clients could listen to FramingEngine if they want to etc..

But sending the message is different - you don't want to have a SendMessage event with zero subscribers, do you? Do you anticipate multiple subscribers sending messages?

OTOH, I think of an interface, like

interface IFrameEngine
{
   event MessageReceived;
   void SendMessage(...);    
}

and have message engine hold a reference to this interface. The dependencies are only one way i.e., MessageEngine depends on IFrameEngine.

Just my 2 cents Smile | :)

Regards
Senthil [MVP - Visual C#]
_____________________________
My Home Page |My Blog | My Articles | My Flickr | WinMacro

Dewald9-Oct-08 5:20

9-Oct-08 5:20

S. Senthil Kumar wrote:
The event mechanism looks ok for the receiving part, but it looks a bit awkard for the sending part.

That's exactly what I was thinking, and what prompted my question. Thanks for at least confirming that. Smile | :)

S. Senthil Kumar wrote:
Usually, people think of events as things that are optional i.e., you can subscribe if you're interested. People also implicitly associate it with multiple listeners.

That makes sense. Thanks, it helps to get such comments. I'm still pretty new to events and delegates.

S. Senthil Kumar wrote:
But sending the message is different - you don't want to have a SendMessage event with zero subscribers, do you?

No, I dont.

S. Senthil Kumar wrote:
Do you anticipate multiple subscribers sending messages?

Nope.

S. Senthil Kumar wrote:
OTOH, I think of an interface, like

interface IFrameEngine
{
event MessageReceived;
void SendMessage(...);
}

and have message engine hold a reference to this interface. The dependencies are only one way i.e., MessageEngine depends on IFrameEngine.

That looks more like what I should have done. Would you mind elaborating a bit? Sorry if I'm asking stupid questions but, believe it or not, I have never used an interface in my life.

S. Senthil Kumar9-Oct-08 5:34

S. Senthil Kumar

9-Oct-08 5:34

Dewald wrote:
Would you mind elaborating a bit?

The interface is to avoid a direct dependency from MessageEngine to FrameEngine, so that you can provide varying implementations of FrameEngine. Something like

interface IFrameEngine
{
event MessageReceived;
void SendMessage(...);
}

class DefaultFrameEngine : IFrameEngine
{
   public event MessageReceived;

   public void SendMesssage(...) {...}

   protected void RaiseMessageReceived(...) {...}
}

class MessageEngine
{
   IFrameEngine frameEngine;

   internal MessageEngine(IFrameEngine frameEngine)
   {
       this.frameEngine = frameEngine;
       this.frameEngine.MessageReceived += ....(HandleMessageReceived)
   }

   internal void HandleMessageReceived(...)
   {
     if (mustSendMesssage)
       frameEngine.SendMessage(...);
   }
}

You could then write a OptimizedFrameEngine, implementing the same interface, and pass it to MessageEngine, and MessageEngine wouldn't know about it.

Regards
Senthil [MVP - Visual C#]
_____________________________
My Home Page |My Blog | My Articles | My Flickr | WinMacro

Dewald9-Oct-08 23:02