|
If this is WinForms, set the form's KeyPreview property to true and handle the form's various key events.
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)
|
|
|
|
|
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();
}
While (true) { Human.isLearnable = true; }
|
|
|
|
|
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...
private _ICommonEnv m_oCommonEnvCOM;
m_oCommonEnvCOM = new clsCommonEnvClass();
Int32 lRet = someVB6COMObject.Init(ref m_oCommonEnvCOM)
Thanks in advance for those who can help point me to useful documentation.
|
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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".
|
|
|
|
|
I think my code has just raised a OnGenerateHeadache() event 
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;
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?
|
|
|
|
|
Sounds good to me - if it works, then 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.
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)
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
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.
|
|
|
|
|
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.
|
|
|
|
|
Excellent! Thanks. I think this is precisely what I need.
|
|
|
|
|
Hi!
I got a problem I've been working on for 2 full days now. I hope someone can help me out here!
Summory:
How can I use a C#.dll compiled in .net v2.0 (v2.0.50727) in a C#.dll compiled in .net v1.1 (v1.1.4322)?
The whole story:
I made a library in C# which validates xml files with an xmlSchema. I include this library in Excel 2003 by following the normal ways to do this.
This all works fine!
Then I encountered the following problem. The system this library needs to run on has Excel 2002 installed! The problem with Excel 2002 is that it looks at libraries as if they are made in .net v1.1. It's possible to work around this problem by telling excel to look at the library from a v2.0 perspective by including an excel.exe.config in the excel directory. However, the users who have to use this library do not have administrator rights and the excel folder is read-only.
I tried to work around this problem by splitting up my library in 2 different libraries.
The first library is compiled as a v1.1 dll (Parser.dll), which i include in excel.
The other library is compiled as a v2.0 dll (XmlValidator.dll) and contains my xmlSchema validation code (not available in v1.1).
I want to make some calls to those v2.0 functions from my v1.1 dll.
And the problem is that I do not get this cross version call to work.
parser.dll
using ...
public class Parser
{
private XmlDocument doc = new XmlDocument();
public string ParseXml(string xmlPath)
{
if (XmlValidator.ValidateXml(xmlPath))
{
doc.Load(xmlPath);
return "parsed";
}
else
{
return "validation failed";
}
}
}
XmlValidator.dll
using ...
class XmlValidator
{
...
public static bool ValidateXmlFile(string xmlPath)
{
doc = new XmlDocument();
doc.Load(xmlPath);
doc.Validate(eventHandler);
if (validationMessage != null)
{
return false;
}
else
{
return true;
}
}
...
}
Both of the above files do what they should do seperately. Or when I include them in the same namespace and compile them both in v2.0.
I've been experimenting with the regasm.exe tool and typelibraries. But I can not find any decent examples from people with a similar problem.
So... any ideas?
Basje
modified on Thursday, October 9, 2008 9:03 AM
|
|
|
|
|
What's .net 1.3? After 1.1, .NET went to 2.0.
|
|
|
|
|
Since I mentioned "v1.3" 7 times... I suppose I'm unable to hide behind a "typo issue".
I did off course mean 1.1, i have no idea why i typed 1.3! Sorry about the confusion!
|
|
|
|
|
One application can only run one version of the framework. To get access to the methods in framework 2.0 the application has to use that version of the framework.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
I hoped to get around this by building them seperately and using something like DLLImport.
|
|
|
|
|
Not going to happen. DLLImports are imported directly into the process using the imported functions. A process can only use a single version of the .NET CLR at any one time. In order to use both CLR's, you'd have to have an external component running as it's own process. Now you're limited to using Remoting methods to talk between two processes.
|
|
|
|
|
I hoped to read something like: "do this, that and it works !"
Anyway, thanks for the info guys! Time to look for a different solution!
-Basje
|
|
|
|
|
Got it working with .Net remoting 
Thx a lot!
|
|
|
|
|
Np problem.
|
|
|
|
|
You might be able to do this by writing a com wrapper in 2.0 around the library you need. The catch being that you'll be limited to COM's more restricted set of data types in your interfaces. Other forms of software as a service might work but I'm not familiar enough with any of them to have an intelligent opinion.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
