I am currently involved in porting a large and complicated VBA application to .NET 4.0.
In .NET I have access to the Profiling API, which I have used to instrument an assembly to extract information about when classes are constructed, methods called, etc.
Is there an equivalent for VBA? That is, some sort of callback system so I can write code which will be notified of events within VBA code as it executes? I've spent some time on Google and contacted several VBA gurus, but to no avail.
A similar question didn't turn up much except a suggestion for a trial version.
This profiler looks free and still available.
You could also search for VB6 Profilers which should also do the job.
Related
I need your help in deciding the best strategy and technology to choose from for the continuing development of a successful in-house VBA application.
In our company (a web-based distributor of financial information), over the years, we have developed a VBA XLA Add-in application for use only inside our company, which helps in the linking of our database of financial information with Excel worksheets, through the use of several UDF's, supported by ADO/SQL and other business objects logic. This app became a solid, fast, and useful tool for us, somewhat similar to old DDE links, but much more sophisticated and flexible than that.
Recently we replaced the ADO/SQL portion of the system with a SOAP based Web-Service and XMLHTTP MSXML 6.0 technology, literally putting our database into the cloud. The goal was to transform the application into a product which could be used outside of our company. That work is already done, and its behaving quite well, with all functionality, load at startup, user authentication and session control login/logout, seamless integration with EXCEL, user-friendly messages, all done in a single 2.036Kb XLA Add-In file, spanning more than 15.000 lines of good VBA code. However, we feel that it cannot yet be distributed like it is...
We feel that in order to be successfully published as a product to our clients, this application must be transformed into compiled code instead of the interpreted VBA. There are many reasons to justify doing that, including security, speed, robustness, etc.. but we don't need to go into these details right now.
Our fist thought was to use VB6 and Automation Designers to quickly transform our VBA code into a VB6 Automation Add-in. Apart from the fact that VB6 is old technology, it seems that Automation Add-in's are not the ideal solution, for our app requires some interaction with Excel events and the End-User, at least during the "login" and "logout" into the web-service based database (and some other functionality that requires user interaction through forms), BUT is seems that Automation Add-ins are not suitable to anything other than UDF's only. Here we would like to learn about other's experiences with Automation Add-ins and end-user interaction.
So, COM Add-in's are the next option. Again, these allow interaction through menu buttons and commands, but do not allow UDF's in the worksheets. Or so we've read. Also, we have read that COM Add-ins can be made as Automation Add-ins (allowing UDF's after all), but that they will work as two separate entities inside the Excel environment (one COM and one Add-In), one half not communicating with the other. That's not acceptable to us. Again, we'd like to learn more about other's experiences in that regard.
Then there is Managed Code (.NET, Interop, and VSTO) as other viable options. However, while simple to get started with, it is not clear that Interop came to stay, and it is not clear what is the best strategy with managed code. Again, we'd like to learn about other's experiences in this realm.
So, the questions final is: given our requirements (i.e., load at startup, access to data through SOAP based web-service (MSXML 6.0), UDF's functions, login/logout session control, user-friendly error handling, etc.), and the fact that we already have 15.000 lines of good VBA code, which is the best technology for us to continue to develop this Excel component, in order to make it into an easily and safely distributable product? All comments and thoughts in that regard are very welcome.
I would take a look at Excel DNA: https://github.com/Excel-DNA
I had a very similar problem developing a VBA add-in that communicates with an ASP.Net Web API. Couldn't really give all the code out in VBA, so we needed a way of giving out compiled code. Connecting to the web service was freezing up excel making it harder for users working with massive spreadsheets with multiple API calls.
You can develop them in visual studios easily using VB so a lot of the code could just be copied and pasted over then changed slightly to fit the later version of VB you're using.
Add-ins compile to .xll 64-bit and 32-bit versions.
We handle all login and connection to the API in the Ribbon: https://exceldna.codeplex.com/wikipage?title=Ribbon%20Customization&referringTitle=Documentation
And you can use newer VB forms which are more user-friendly.
Connect to other .dll files for sharing logic across multiple add-ins.
The UDF we use which call the API can all run asynchronously freeing up Excels main thread.
https://exceldna.codeplex.com/wikipage?title=Asynchronous%20Functions&referringTitle=Documentation
It can run any VBA specific or CAPI code by queuing as a macro.
Pretty much do everything that you could do in VBA plus more.
Govert the Developer https://stackoverflow.com/users/44264/govert is very active on StackOverflow and forums. He's helped us out loads in the development. And Excel DNA is still being updated and worked on.
Let me know if you want some more details.
great summary of your project.
I'm also curious what other thinks about the "right" solution for such task. It won't be an easy decision though.
My short answer will be "stick with VBA" unless you are really concerned about stealing your code from the great VBA add-in.
The reason I'd go for VBA is that the longer I've been working with VSTO/COM the better I've found VBA to be the best for handling tasks that are closely related to Excel (understand MS Office) object model. I'm saying that even I have written almost zero lines of VBA code in last 4 years. I do understand that you are using webservices and other dependencies but I'd say that if you have good progress and the add-in is working as expected I'd NOT throw myself to a completely new world of development (VSTO & C#) just to be cool, you will gain not too much value of this, especially if you know that
deploying managed code is harder that just copy your add-in to a
folder, set registry, done
troubleshooting is a way harder with managed code, basically you will have to log much more and trying to reproduce issues that may not happen in your environment but happens in clients
re-engineering of managed code is not such hard so if people really wants to steal your code they can do that unless you use obfuscation
and the last and probably the most important for you as much as I'm aware there is no easy way to do UDFs in VSTO
I have very minimal experience with VB6/ COM Automation so I'd love to hear opinion of guys who have done something similar before
Re: the VSTO & UDF, at my job, we have a VSTO add-in that somehow handles UDFs for a large project. I'm not the main developer of the application but I believe we use Excel DNA there so do check it to explore the managed code option further
Hope that helps
I would like to subscribe to a RabbitMQ message queue from Excel 2013.
The ultimate aim is to allow data contained within a MQ message to be processed within Excel and to also allow Excel to send a formatted message via a RabbitMQ message queue.
Is this possible?
The message which is sent down the message queue is comprised of 7 fields, each field is delimited by a ; symbol - however the message is sent as one string over the message queue...
e.g. "text;number;number;number;text,text,timestamp"
I would like to be able to split the raw message as above, into formatted cells in Excel 2013.
Can this be done?
I have limited coding experience and I am trying to learn so please forgive me if this is a 'silly' question.
Any pointers will be much appreciated, for example can this be done via VBA code or an Excel Add-In?
Thanks in advance...
First, the bad news: there is no easy way to do this.
Now, the good news: if you really want to, you probably can do it, in at least two different ways.
Disclaimer I have not tested anything, cannot guarantee that it will work, and you (probably) will need to level up your coding skills to achieve what you want. These are just ideas that I would explore myself if I had requirements like yours, and should give you some pointers to get started. They're not necessarily good or functional.
There are various approaches to explore in order to achieve what you want:
Write an Excel addin in .NET to actually consume/publish to the queue. This may actually be the easiest solution, but it requires both Visual Studio and a bit of .NET knowledge. Some good resources to get started:
https://msdn.microsoft.com/en-us/library/bb157876.aspx and the always-so-good https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html .
Pros: probably the easiest solution
Cons: you'll probably end up with an addin tied to your current requirements, and will have to update your addin when specifications change
Leverage COM Interop in .NET to write a wrapper DLL around RabbitMQ's .NET client library. If you've never done .NET, this approach may not be appropriate, as it will involve marshalling datatypes and function pointers. Some more pointers if you choose this (difficult) path: Easiest way to make .NET DLL visible to COM?. You can then import your COM wrapper into any Excel/Office project by adding the generated DLL to your VBA project.
Pros: you can create a generic wrapper that exposes RabbitMQ to Excel VBA and reuse it in any other Excel based project
Cons: the learning curve will be steep.
Use the STOMP adapter on your RabbitMQ server (if you have that option available, which may or may not be possible depending on your setup/sys admin), and write your own implementation in VBA. This is a bit hardcore, but works without any .NET voodoo, but you will need a special ActiveX control called MSWINSCK.OCX, and some event handling. StackOverflow has a question with decent answers samples here: MSWinsock.Winsock event handling in VisualBasic
Pros: once again, you can create re-usable code (via a class that you can import in other projects)
Cons: you have to implement a protocol, and it depends on an ActiveX control. Also requires the use of a RabbitMQ adapter, which you may not be able to use in your context.
I'm sorry that I can't provide actual code showing how you'd go at any of this, but as you've probably guessed by now, all solutions imply a fair amount of work. So at least, you know where to look...
Can anybody explain how can i call .net methods(from .dll) in my java code but i dont want to write/use C/C++ Code please expalin it Step by Step
You haven't given us any information to work off (How large are the two projects? Are you forced to use a specific CLR/JRE? Can they be two separate processes or do you just need to access a bunch of methods? Stuff like that), but I can point you in a general direction...
IKVM.NET is an implementation of Java that runs on the CLR. If you run your Java program in there, you can interop with any other .NET language easily.
If you can't use this for some reason, then you're probably going to have to embed Mono in your application and write some JNI bindings to start an instance of the CLR, then load and invoke your code.
If you've got a small amount of methods, consider just porting the code to Java instead of creating this huge system in order to get a small amount of functionality.
I can't explain it step by step because you haven't provided very much information as to what restrictions you have or how it needs to be done. Also, this isn't something trivial. You're trying to get two language runtimes to interact with each other without using native code, when native code is the only thing either runtime can interoperate with.
Is there any way in visual basic to display any of this information about memory(like in the link below)?
Something like Module Name,Serial Number,Module Type,Memory Speed,Timings etc. ?
As Damien_The_Unbeliever stated your best bet would be to look at the Win32_PhysicalMemory WMI Class. You can experiment around WMI by downloading the WMI Code Creator from Microsoft, it will generate code in C#, VB.Net and VB script which you can run through the program and see what the results are.
I believe what you are asking is how to retrieve information about hardware components (namely main memory) using VB.
Please see this thread on VB forums on some example of accessing hardware information.
You might also be interested in this a bit more as it seems to cater to your needs a bit more.
Good luck.
I would like to hear of the experiences of classic vb developers who migrated their applications to delphi rather than vb.net. How has it worked out? Are you glad or sorry that you didn't move to vb.net?
I am not really a vb developer but rather a Delphi developer who was forced to maintain some vb apps for a while. I tried to migrate one vb app to vb.net and after that experience I never tried it again. I successfully migrated several vb apps to Delphi. It wasn't easy and it became a pain in the lower back to find native Delphi replacements for some of the OCXes that had been used (I will never again rely on a third party library for which I do not have the source code.), but it worked out OK.
But as said above: I am an experienced Delphi developer, so I didn't have to learn Delphi at the same time as migrating a vb app. That certainly made it much easier.
I just spotted this on DelphiFeeds:
Delphi for Visual Basic developers
Help to migrate VB applications (knowledge and skills) to Delphi
I had a good friend who moved from Classic VB to Delphi a while ago (back before .NET). He was really happy with the move.
The company he worked for made applications in VB, and they put together a special team (2 developers) to create Active X controls in Delphi for the rest of the company to use. Additionally, when there was something that they couldn't do in VB then the Delphi team would do it. That was when he was introduced to Delphi.
He said it didn't take long before the Delphi team could prototype applications in Delphi faster then the rest of the development group (he never said how large, but way more then two) could. The company never made the switch to Delphi from VB because someone was under the impression the VB was a better solution despite the evidence that Delphi was more powerful and faster.
A few years are I was working with another student on our placement year. We worked for a very large manufacturing company. One of his projects was to create a classic VB app to interface with multiple cameras on a production line and analyse the data in real time. In classic VB this was a shambles - it took on average 1.5 minutes to process a single frame from a single camera (7 cameras at 24 fps) there was no that he could optimise it.
He eventually took the plunge in to Delphi and re-written that app and works fantastically. I've recently been in contact with a few friends who still work there and his app is been running smoothly for 3 years now.
I've worked in both VB and Delphi, and Delphi is (IMO) much less frustrating/limiting. You should be able to use ActiveX / OCX controls as needed (though I agree w/other comments re: avoiding there where you can, and being sure ot have full source code). Apps we've migrated from VB to Delphi (two) have gone well.
I did try in two instance to migrate from VB to Delphi but unfortunately I had to abort midway in one app as it used a lot of third party ActiveX (most from ComponentOne and a few from CodeJoke). We had to abort midway as we could not find any VCL components having equivalent functionality to the ActiveX used in the project.
It was a nightmare for us. Thank god we aborted midway and switched to C#. It was unbelievable that we could get all the features in .NET component to the ditto!
The app we managed to convert, went well off but we had to get rid of a few features that we had implemented in the original software as they required more work in Delphi.