Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
.NET
#1
it would be cool to use qm for making .net executables.
pi
#2
Some .NET classes can be used as COM objects. Example:
Macro
Code:
Select All      Help
IDispatch s._create("System.Collections.Stack")
s.Push("aaa")
out s.Pop

But most classes can't. For example this code fails:
Macro
Code:
Select All      Help
IDispatch d._create("System.IO.Directory")

List of classes that can be used:
Macro
Code:
Select All      Help
int n i
BSTR b.alloc(1000)

for i 0 1000000000
,n=1000
,if(RegEnumKeyExW(HKEY_CLASSES_ROOT i b &n 0 0 0 0)) break
,str s.ansi(b)
,if(s.begi("System.")) out s

Also can be used mscorlib type library but for most classes it contains only CLSIDs, and you can create only some classes.
Macro
Code:
Select All      Help
typelib mscorlib {BED7F4EA-1A96-11D2-8F08-00A0C9A6186D} 2.0

IDispatch s._create(uuidof(mscorlib.Stack))
s.Push("test")
out s.Pop
#3
I'm still new to this - but I'm having trouble connecting to an app via their published API because I can't register a certain DLL. From what I see here - this either because it's a .NET object and not a COM object or (a colleague suggested) there may be some dependencies that aren't handled.

I need to use the TcpChannel class from System.Runtime.Remoting.Channels.Tcp (in System.Runtime.Remoting.dll) http://msdn.microsoft.com/en-us/library/...s.90).aspx.

I've run the macro here that displays the contents of the registry and there isn't anything for TcpChannel.

I've tried to manually register the DLL in C:\Windows\Microsoft.NET\Framework\v2.0.50727. This fails.

My conclusion is that I'll have to create my own COM wrapper to call from QuickMacros and link TcpChannel from there. Is that correct? Thanks.
#4
I also did not find a way to use this .NET class in QM directly.

See also CS Sript: http://www.csscript.net
#5
I see that CS-Script does the following:
Quote:The main idea of CS-Script is to allow "plain vanilla" C# code execution from both command-prompt and form any CLR application hosting the script engine.

Simple deployment approach: just bring both script and engine file (about 100 K size) on the system that has .NET runtime installed and script can be run

All .NET functionality is available (FCL, COM Interop, Remoting, WPF, WCF etc.).

Portability: Scripts can be run on any system, which has CLR installed (including Mono).

So are you suggesting a possible solution is for .NET functions to co-distribute CS-Script with QM-generated exe's and call when necessary from QM-exe for those .NET functions?

That would work for me....gotta learn a little C# now! Big Grin
S
#6
Any future option to include VB(.NET) code execution since C# (.NET) code is already included in beta version now.

The vb code is much easier for me to understand and learn compare to C#.
#7
Ok, will add it in some QM 2.3.5.x version.


Forum Jump:


Users browsing this thread: 1 Guest(s)