I want to know if I can directly read or write values in the current process in a Visual Basic 2005 Windows application.
Like *(DWORD*)(0x123456) = 1; in C++ will write the value 1 at the address 0x123456.
So anyway to do the same in VB using only built in functions and not using ReadProcessMemory and WriteProcessMemory?
If you are really sure you need to do this you should look into the Marshal Class, specifically Marshal.WriteByte.
But I am pretty sure Marshal makes heavy use of Win32 API functions so it's questionable if it's really "built in".
Related
I'm building an add-on UI system in VB.NET (Visual Basic specifically) that uses data from a legacy Microsoft Access system (that will at least for some time needs to be useful via its old, internal UI). I can do pretty much everything I need to do from VB.net - work with the data tables, call Access functions that contain decent functionality, etc.
What I'm trying to figure out is if Microsoft Access can call back to VB.NET (e.g., perhaps allowing me to pass in a function reference to be invoked).
The specific motivation is that there are 2 or 3 time-consuming Microsoft Access functions that produce critical output data - if you were invoking them directly via the MS Access interface, you would see things like progress bars and the occasional text update on a form of the work phase, progress %, etc. I can modify the MS Access code not to do these things if called from VB.net, but I'd really rather have the MS Access code reach back into VB.net so that I can provide some progress feedback in the new interface.
An elegant solution would be, as alluded to above, have VB.NET pass in the function delegate for MS Access to call - but as these are entirely different memory spaces, etc., I would think some internal framework would be required to get such a thing to work - perhaps via a shared DLL in some manner. I could go the old "polling" route, wherein MS Access writes out status to a table, and the (asynchronous) VB.NET app polls that table and uses what's there. That seems like such an inelegant hack, unnecessarily wasteful in resources and potentially bug prone, that I hate to go that route. If I could build just one function that MS Access could use, something that just passes a status string back, I think that'd cover the vast majority of cases.
Any suggestions would be most welcome.
I often create COM objects in .net for use with Access. Thus in your access code you could MOST certainly have the process loop “call” the .net object to update the process.
However, you likely are automating a copy of Access, and thus would like Access to call a routine in the EXISTING automation client, not have an instance of Access call a custom .net object. However, I think building a custom .net object would be the least work and hassle. In other words, you flip your approach around. You launch Access first and it uses your .net application as a COM object. That way, any routine in your application would be useable and callable from Access VBA.
The ONLY reason why I would walk down the road of implementing a call back if the main .net app REALLY needs to receive messages from Access as opposed to Access simply calling + using a custom .net object to display the process information. (so VERY easy to build a .net object for showing progress).
So best bet is to adopt the idea of turning your existing application into a COM object to be consumed by Access. This is VERY easy.
Once you do above, then
Access is launched first and then creates the instance of your application. (and thus can call/use any .net sub or function expose in your .net application from VBA).
And even if you don’t launch Access first, Access on startup could grab a running instance of your application (just like you can pick up a running instance of Excel or Word in Access/VBA).
Last but not least;
You probably can implement call backs, but I simply don’t know if this is possible without having to create a .net COM object as a go-between. As such, likely best to have Access just pick up a running instance of your .net application anyway.
So I would expose your .net application as a COM instable object.
So least amount of work would be to create a separate .net COM object that access uses, but if you assume for future that VBA should be able to call any vb.net routine then I would thus just build your .net application as a consumable COM object.
Visual C++. I have to implement some drawing and printing functionality that will be incorporated into (other developers') COM dll. Firstly I thought of doing everything using pure GDI and nothing more, but it seems that printing and print previewing is hell of a job to be done in GDI compared to the MFC implementation. So I decided to focus on MFC. Quick side question here: Is my choice right? I mean, are any easy ways of implementing printing (and print-preview) without MFC?
Now that I need MFC (assuming if you also agree with this), I have two questions about how to do it:
1) I believe the COM dll is the ATL project (it's not my code, some other developers independently develop it). Can I enable MFC support in that dll? What are the risks/limitations/drawbacks of having MFC runtime in the COM server? And if you advice doing this, how can I do it?
2) As much as I want to affect the third-party COM server's code as little as possible, I thought it might be the better approach to implement my code as a separate MFC-based DLL, and load and use that DLL from COM server. Do you advice doing this? What are the risks/limitations/drawbacks in this situation?
Shortly, I want to use MFC's drawing and especially printing capabilities in my code, which itself should be integrated in another developers' COM dll (which itself is utilized in a large corporate application). I'm no expert in COM technology so I'm a little bit confused. What are my best options?
You can use MFC in your own dll internally, and expose functionality to your users with non MFC intruded function: for example if you need to pass a point from/to ypur caller, use the GDI standard POINT structure, then convert it to a CPoint to use internally. In this case you don't need to enamble use of MFC in the ATL project ( that is possible anyway ) but of course you need to distribute or link with the MFC dll. If you want mantain the caller com dll as clean as possible, you can definitely create your own ATL+MFC dll and expose your functions via com interfaces too, but keep in mynd to avoid put MFC related objects in the interface.
Printing and print preview is a hell of a job unless you're using MFC Document/View Architecture. Will your COM expose such advanced UI?
If your COM must be independent of .NET then MFC is the way to go, otherwise I would use .NET. If you choose MFC, make sure you link to it statically. Otherwise you will most likely end up with runtime errors on machines where the necessary MFC version is missing.
Except for this, I wouldn't worry about compatibility since the idea of COM is to let the underlying magic do the marshaling of integers, strings and other objects.
I would like to access a WCF service through VBA functions/macros in Excel (2007 or 2010).
It seems there are a number of possibilities, each with its own particular shortcomings. ...
Microsoft SOAP Toolkit
WCF Service Moniker
COM Interop
VSTO
Excel-DNA
Can anyone advise on the best way of doing this?
I don't think there is a clear-cut answer to your question; it depends a bit on what you want to do with the data returned from the service, how you intend to deploy your solution, and how much is done with VBA, as opposed to .NET.
My gut feeling is that VSTO is probably right, because it gives you a full-fledged .NET project, which will likely be the most convenient to handle the WCF services. Assuming that what you are trying to do is retrieve data and give your user choices as to what to pull and how to display it, you can then build a user interface for it (maybe in a task pane), and write the results to Excel, while writing code in Visual Studio.
However, you mentioned VBA, and I am not quite sure how much you want to use it. I found ExcelDNA to be easier to use if what you want to do is create a VBA user-defined function which calls a .NET dll. If VBA is what you want to focus on, this may be the way to go.
Hope this helps!
I've got a game in VB6 and it works great and all, but I have been toying with the idea of creating a scripting engine. Ii'm thinking I'd like VB6 to read in flat text script files for me and then lex/parse/execute them.
I have good programming experience, and I've built a simple C compiler, as well as a LOGO emulator before.
My question is:
Are there any tools that I can use, like Lexx/Yakk/Bison to help me? How should I approach this problem in regards to lexing, parsing, and feeding the commands back to VB6 so I can handle them? Is this idea a BAD IDEA in the sense that there are too many obstacles in the way (For example, building minesweeper in assembly, though not impossible, is very difficult, and a bad idea.)?
Use the Microsoft® Windows® Script Control because it is easy to integrate into existing VB6 applications. The control supports VBScript, JScript, or any other "Active Script" implementation.
I have used the Windows Script Control in four projects and it works extremely well. Very easy to integrate. I wish Microsoft would have given us a replacement in .NET, and made it as easy to use. (I understand the control is not needed in .NET, but having the ability to simply create an object that handles everything is nice.)
Windows Script Control
The Microsoft® Windows® Script Control
is an ActiveX® control that provides
developers with an easy way to make
their applications scriptable. This,
in turn, enables users to extend
application functionality through
scripts, much as they do with macros
today.
INFO: Where to Obtain the Script Control at http://support.microsoft.com/kb/184739. Includes links to other howto support articles.
Chapter 13: Adding Scripting Support to Your Application at http://msdn.microsoft.com/en-us/library/aa227413(VS.60).aspx
Designing a Calculator at http://msdn.microsoft.com/en-us/library/aa227421(VS.60).aspx
How To Use Script Control Modules and Procedures Collections, Inserted from http://support.microsoft.com/kb/184745
How To Use the AddObject Method of the Script Control, Inserted from http://support.microsoft.com/kb/185697
SAMPLE: SCRIPTEX.EXE Uses the ScriptControl with Visual Basic, Inserted from http://support.microsoft.com/kb/189484
Windows Script Control can be downloaded at http://www.microsoft.com/downloads/details.aspx?familyid=d7e31492-2595-49e6-8c02-1426fec693ac&displaylang=en. (Supported Operating Systems: Windows 2000; Windows 98 Second Edition; Windows ME; Windows NT; Windows Server 2003; Windows XP)
MSDN Search of "MSScriptControl.ScriptControlClass" at http://social.msdn.microsoft.com/Search/en-US?query=%22MSScriptControl.ScriptControlClass%22&ac=8
MSDN Search of "Windows Script Control" at http://social.msdn.microsoft.com/Search/en-US?query=%22Windows+Script+Control%22&ac=8
MSDN Search of "MSSCRIPT" at http://social.msdn.microsoft.com/Search/en-US?query=MSSCRIPT&ac=8
Unless you're doing it for your own instruction, you may want to try using Lua: VB6 - Lua Integration
If you're willing to use VBScript rather than VB6 you might be able to just use the MSScriptControl to run the commands rather than creating your own. Here's an article discussing using it from a .Net app, though it's an ActiveX control so should give you quite a bit of flexibility.
The control can be downloaded from here.
I've actually seen some quite reasonable implementations of compilers/interpreters in VB6[1] - It's not the language I would choose (few functional features, insufficent static type system), but with experience, you can outweigh these drawbacks and be quite productive - So why not.
You can use the GOLD parser generator that supports VB6 as a start.
[1]: Somewhere on PSC or in this download repository I think ...
Note that there is the MSScriptControl too.
There also appears to be an additonal alternative for VB6:
SadScript is an variant of VB6 most prominently used for VB6 as an scripting engine in MMORPGS .
See here for more : What is sadscript? Can I use it in vb.net? Why hasn't anyone I have asked heard of it?
We are in the process of creating active-x controls used within our application.
Since Microsoft stopped supporting classic Visual Basic, is it wise to use Visual Basic to develop the Active X control or the latest VC++/ATL/MFC libraries provide more feature where we can create controls faster by leaving Visual Basic flexibility?
We will not be able to use .NET/VB.NET/C# since the application is supposed to work inside containers and containers may not support latest .NET runtime.
Any other language is best fit for Active X control development other than VB and VC++?
I, personally, would recommend using Delphi for this. It is still actively developed, and has the control you get with C++, but a rapid development environment more like VB.NET.
#nobugz: If you are really interested what is ActiveX in Delphi, look at docwiki. Normally it is 100% source code (yours + VCL, VCL is also available as sources) with autogenerated COM wrappers. So all potential security problems are also in source code. If you find a security problem in VCL, please send a bug report to Quality Central.
Here is a good example on how to create ActiveX Controls with C# .NET
http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx
By all means VB6 is the best language. After reading your question I feel that you are a VB6 developer. If you know VB6 and use it then why hesitate using it for producing ActiveX controls.
I program in Delphi as well as VB6 along with VB.NET and C# but creating ActiveX controls is the easiest in VB6 compares to all other development tools.
If you are hell bent on not using VB and if you are looking for an alternative then try out PowerBasic (commercial - very costly) or PureBasic (commercial but affordable) Get it from here or better still MinGW (a GNU C++ compiler).
I have to say that VB6 with a good book like Developing COM/ActiveX Components with VB6: A Guide to the Perplexed you will be up and running faster.