|
I'm working on an application that will use a custom input device, supplied by the client, which connects to the parallel port. They've given me a disagram which looks like this
25 Status 0 1 2 3
11 S7 ML H Men LF
15 S3 LB A/T PB A>>Z
13 S4 Z<
|
|
|
|
|
|
No, because I need to interact with the parallel port, not the serial port. Is there some way I can use that article to access the parallel port ?
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Sorry CG, I missed that part.  If I see something I will let you know.
- Nick Parker
My Blog | My Articles
|
|
|
|
|
Maybe this link will help:
Interfacing the Enhanced Parallel Port[^]
If I had to make a guess (without seeing an actual schematic of the device) - S3 probably corresponds to Base+3 which is an EPP address port and S4 probably corresponds to the EPP data port - so you have to send information S3 (the request) and then read informationfrom S4 (the response). I don't have a good guess about the other stuff 
Steve
|
|
|
|
|
I have been trying to figure out the best way to run a script(any kind...vbscript, Jscipt, JavaScript..whatever works) inside a c# application. I've been looking at WSH, VBA, and script component stuff and can't seem to figure out how to use these and which one actually does what I want. I want to be able to send a parameter to a script method, like an integer, and have it return the parameter altered (multiply it by two). Just a proof of concept thing. Also, I don't want to use IIS, so ASP is out!
I'm new to .Net/C#/Windows programming, so this has not been easy for me!
Thanks for any help in advance!
-Johanna
|
|
|
|
|
|
There was a discussion on this yesterday. I suggest you browse through this forum or use the "Search comments" link above.
The scripting environment and the .NET Framework are two completely different things. Scripting revolves around OLE/COM Automation, while the .NET Framework revolves around the CLR (Common Language Runtime).
There articles on MSDN Online[^] and this web site. A good starting point is Interoperating with Unmanaged Code[^] in the .NET Framework SDK. Experience with COM development is very useful. There are also a few books available on COM interop with .NET that you can find on Amazon[^] I recommend you pick up, especially since you're new to Windows and .NET development.
This site - CodeProject - is also a useful resource but keep an eye on the article ratings. Just because someone posts an article doesn't make them an authority on the subject (true for everything else on the web).
Software Design Engineer
Developer Division Sustained Engineering, Microsoft
My Articles
|
|
|
|
|
Heath,
Okay, I think I found the discussion you were referring to - I had ran acrossed it before while searching for help on this subject before (I have done quite a bit of searching on both cp and msdn...i must be using the wrong code words...) I just had to read and re-read the article a bit to see how it applies...
This is now my understanding - I can interact in some way with scripted code using COM objects in some fashion (VSA? Windows Script Components?). I do understand there is a difference between COM and .Net, I just didn't find in my research that the scripting environment was a COM thing.
By following a link from the discussion you referred me to ( generating and compiling source code), I am now under the impression that as long as I write JScript code, i can compile and run my code using the System.CodeDom classes.
Please let me know if I am right about this!
Thanks for your help, I do appreciate it.
-Johanna
|
|
|
|
|
johanna42 wrote:
By following a link from the discussion you referred me to ( generating and compiling source code), I am now under the impression that as long as I write JScript code, i can compile and run my code using the System.CodeDom classes.
Any language targeting the .NET Framework can access the System.ComDom namespace (assuming it's running on Windows), however what you need to understand is that you can't write an assembly in C# and then simply write a VBScript file where you can call CreateObject and use your C# classes within the VBScript. There are ways to generate MSIL at runtime and invoke them; however again, this is entirely different than OLE Automation's mechanism for late bound objects in VB/VBScript.
- Nick Parker
My Blog | My Articles
|
|
|
|
|
Nick Parker wrote:
what you need to understand is that you can't write an assembly in C# and then simply write a VBScript file where you can call CreateObject and use your C# classes within the VBScript.
Maybe I'm not making myself clear. I don't want to access my C# code from VBScript, I want to do the opposite. I want to invoke a method in my VBScript from inside my C# code. I'm not trying to create a com object to run my .Net stuff, I know better than that!
I have seen examples on msdn (using Windows Scripting host setting up your script to be read as a COM object, using VSA by attempting to compile and run a script, trying to figure out how to pull in WSH into my code) but I can't figure out which of these ways are valid, reasonable solutions(or if none of them are).
I guess what I was trying to say is if I used JScript as my scripting language (which runs on CLR as far as I know), then I can use the .Net namespace System.CodeDom (inside my c# code)in order to run the script. Is that correct?
Also, if I am attempting to read VBScript or some other scripting language, then I assume I have to use some other non-.Net scripting engine in order to compile and read the script. From what I understand of the past e-mails, this engine may only exist in COM terms and I will need to understand how to use com objects with .Net stuff.
If this is all wrong, please let me know!
thanks,
Johanna
|
|
|
|
|
Dear Johanna,
adding scripting capabilities to .NET programs is, indeed, possible.
There was an article on that subject in a german .NET magazine some time ago. Here's the link to a sample project (comments in german, though):
Scripting .NET
The sample shows how to set up a scripting host in your program, make objects available to scripts and how to load and execute JScript scripts to modify your application's behaviour.
If you have problems with understanding the code or comments, then drop me a line, I'll translate.
Regards,
mav
|
|
|
|
|
mav,
This example is *exactly* what I've been looking for! Now, I just hope I can get through the German enough to understand what the heck I'm doing! I appreciate your help! I was kind of under the impression that VSA might be the way to go!
Thanks again!
Johanna
|
|
|
|
|
You still need to expose your .NET components - your object model (OM) - as COM objects, though. You can embed the scripting engine (I never said you can't; only that .NET is not a script host itself and that scripting revolves around COM) because it itself is a COM component (so you create a CCW, or COM-Callable Wrapper), but in order for script to access your object model you have to expose COM objects.
I'm not sure why you stumbled into the CodeDom. What you need to read is Interoperating with Unmanaged Code[^].
Software Design Engineer
Developer Division Sustained Engineering, Microsoft
My Articles
|
|
|
|
|
Sorry to contradict, Heath!
The sample doesn't use COM interop to achieve scripting abilities. It revolves around Microsoft.Vsa.IVsaSite.
The application implements a scripting host and executes JScript scripts in this context.
Using IVsaGlobalItem the scripting host can publish objects to be used in the script (quite similar to what Word does in a VBA script when it exposes the global Application object, for example).
I'm thinking about writing an article on that subject when I have time...
Regards,
mav
|
|
|
|
|
mav.northwind wrote:
quite similar to what Word does in a VBA script when it exposes the global Application object, for example
The Application object is an OLE/COM automation object implementing IDispatch to provide late-binding.
.NET is the natural progressional of COM and if you expose an entire assembly to COM (use ComVisibleAttribute at the assembly level) then there's no problem, but this doesn't follow good COM programming guidelines and you will run into problems (re-ording the methods in a class, for example, can screw up both late- and VTBL-binding).
Now, if you had something to marshal calls to your assembly that was a managed host, then you wouldn't need to expose COM yourself. But like it or not - and trust me on this - script relies on COM 100% (automation) so something has to expose your .NET components to the script engine.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles]
|
|
|
|
|
Calm down Heath,  I didn't want to doubt your overall expertise, we're just talking about two different things.
I just wanted to illustrate what I meant with global objects, I didn't say the mechanisms involved are the same.
Sure, deep down Word.Application implements IDispatch and VBA invokes the methods over this interface. I never said it wouldn't.
But from what I've seen while browsing through the sample code you _can_ publish objects to be accessable from a script executed by IVsaEngine. This is done by calling IVsaItems.CreateItem() and the object published does _not_ have to have a ComVisibleAttribute set to be usable in this context.
Sure, the objects "published" in this way will never be usable from a VBA macro or a WSH script, but I think that wasn't what johanna42 meant.
mav
|
|
|
|
|
I wasn't upset, but tend to get so when people tell me to "calm down".
If IVsaItems.CreateItem (or rather the implement of it) is exposing objects, then it - as I mentioned in my previous post - is marshalling calls from COM to .NET.
Trust me - script revolves and exists solely on automation. Not only do I speak from experience and from what's written in the Platform SDK documentation (among other places), I'm actually working with script source at Microsoft.
The fact is that script wouldn't work without automation. IDispatch is not "deep down" - it is the heart and soul of automation. It - along with ITypeInfo - exposes properties and methods of an object. This provides late-binding to script which calls IDispatch::Invoke with the DISPID of a member (cached or not) along with DISPPARAMS (basically an array of VARIANTs) and other information if necessary.
Every type in an assembly actually has a GUID associated with it. If you use the GuidAttribute, this GUID is fixed instead of assigned at compile time (whether you expose the type to COM or not). It very likely that the implementation of IVsaItems is using that GUID to create objects and to identify the class in order to marshal calls and expose type information (all of which can be easily done thanks to the type metadata).
This still relies on an automation layer, except that you aren't actually registering your coclasses and interfaces, nor a typelib.
Still, you can embed the script host and through the engine expose the objects so long as something is providing a class factory and is marshalling calls.
Scripting your application would only work within your application so long as it provides a root object (like the Application object) from which the OM flows.
Software Design Engineer
Developer Division Sustained Engineering
Microsoft
[My Articles]
|
|
|
|
|
Heath, you sounded _a bit_ upset, but my "calm down" wasn't completely serious either (mark the smiley).
I suggest we end this discussion here because it's getting more and more academic.
Scripting relys on automation, agreed.
Using IVsaEngine in your application and exposing objects using IVsaItems.CreateItem() doesn't require you to think about how to automation-enable your objects' classes.
IVsaEngine may or may not use IDispatch internally to marshal calls to objects' members - it simply doesn't matter from a class user's point of view. With enough effort you or I could fire up reflector and prove one point or the other but right now I think it's useless effort, as long as an IVsaEngine implementation does what it's supposed to do.
Johanna42 got what (s)he wanted, and that's what this forum is all about, isn't it?
If you disagree then I suggest we'll continue this discussion in the general or COM forum, ok?
Best regards,
mav
|
|
|
|
|
|
Has anyone encountered a control (text box or RTF) which supports all of the great features of the RichTextbox control, but also supports drag-and-drop? For some reason, Microsoft exposes the drag and drop abilities only to themselves internally. 
This signature left intentionally blank
|
|
|
|
|
|
Nick,
Heh heh ... I read all of the documents on drag-and-drop operations with the RichTextbox and how easy it is as well. Unfortunately, if you go into VSS and lookup RichTextBox.DragOver you will see the following message:
This member supports the .NET Framework infrastructure and is not intended to be used directly from your code.
As a result there is no way I can wire in my handlers since there are not events exposed.
And that is why I am looking for an alternative.
This signature left intentionally blank
|
|
|
|
|
Would something like this work?
public class RtbDerivitive : RichTextBox
{
public event DragEventHandler DragOver;
protected override void OnDragOver(DragEventArgs drgevent)
{
if (DragOver != null)
DragOver(this, drgevent);
base.OnDragOver(drgevent);
}
}
Judah Himango
|
|
|
|
|
He shouldn't need to subclass the RichTextBox to perform a simple drag and drop operation, see my example below.
- Nick Parker
My Blog | My Articles
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
