Windows allows us to print specific PDF files manually from the printing options. I only need a PDF reader (which can be free) to open the file, then print it by entering specific page numbers. However I couldn't find doing this process programmatically without using any third party licensed PDF program or library.
I am looking way to do this using MS VBA 2003. Is it possible?
I did what I aimed by using an COM exposed C# application.
The PDF printing library was easy to find as a C# .NET project, therefore I produced my own .dll file by creating a .NET C# Class library project. In this application, I used the library called PdfSharp which is opensource. I wrote my code in order to expose it to COM.
After I registered my produced .dll and created a .tlb file, I referenced this .tlb file to my Access Visual Basic editor. Voila! it worked perfect.
Related
I am putting together a VSTO addin for MS Outlook. The addin is designed to utilize a unmanaged C++ library. Access to the library is via a C++/CLI (CLR) project. I am receiving a
File Not Found
error when running the ADDIN directly. It appears that the addin has difficulty with the associated unmanaged C++ library. The library is completely packed within the C++/CLI project and nothing using it requires knowledge of the unmanaged C++ library. The strangest aspect of this situation is that If I launch the ADDIN from Visual Studio all is loaded properly. I've validated that all libraries being used are where they are suppose to. It is unclear to me why the addin would fail to launch (when not being launched from Visual Studio).
Note: I validated this by running a test where I created a C++ library with one class and a C++/CLI library with one class that instantiates the class from the first library. I attempt to connect to the C++/CLI library from a VSTO project. I get the file not found error. I felt this was the simplest test to validate / determine what was happening.
Peter
Peter
The issue dealt with my making assumptions based on where things were placed. I had an installer that deployed the addin to the target deploy location. All files went into this folder. MY thinking was that if all the libraries are located within the same location they should all be found. This was based on the my thinking that an app runs and looks locally first for files. My mistake was that the app being run was Office Outlook - and it runs in a specific folder location. When I got the file not found I was thinking this can't be because the files are all together. BUT Office products when loading ADD Ins do not look in the location that the Add In is identified to be in (at leat for un managed DLLs - managed -- maybe different).
The end result was that the unmanaged DLL was not locatable because it did not show up in any of the seath locations of Windows. So the correct was to update the path to have the location of that add in. Which solved the issue of not found. What is annoying is that Visual Studio debugger -- looks to be working on the aspect of identifying DLLs where the application is being launched from. Which in general is fine -- except with VSTO the app being run is somewhere else -- but VS still looked in the project folder location to find the files. Making it somewhat unclear. This should not be occurring. VS debug should try or at least be configurable to operate in the context of the real world scenario. If it does -- I certainly was not able to find that configuration.
Peter
I am using writing in Visual Basic using Visual Studio 2013 and trying to use the debuger for code in a DLL that is outside of the working directory. The dll is a c++ project and the main app is a VB project.
How do I do that? In c++ it seems to be straight forward but not with VB.
Below is purely for background. I am interested in the question above in general and this is just the latest manifestation.
The full story: I am trying to debug the VB program and a DLL written in C++. I copied the the DLL into the working directory of the VB exe directory. But it gives me a tool tip at the break point in the DLL source code that reads "breakpoint will not currently be hit. No symbols loaded for this document." I am trying to figure out if that fixes the problem. If it does, it does. If it doesn't, it doesn't.
Pehaps you should p-invoke (enter link description here) to make a call and import that .dll. The other option would be to register dll in gac and make wrapper com for your library.
You should also add the library to your .NET application as follows:
xcopy "$(SolutionDir)DLL\$(ConfigurationName)"\*.dll "$(TargetDir)"*.* /Y
Project-->Properties-->Compile-->Build Events-->Post-build event command line pass the command.
I have a file-translation library in the form of a Win32 EXE and a stub DLL that feeds parameters to it. I have written a lightweight (~500 lines) VB.net app that creates the file to be translated, then calls the DLL to launch the EXE. Unfortunately, this results in my EXE, their EXE, the DLL and another supporting file. I'd prefer to have a single file.
Following the basic idea here doesn't seem to help - I need to have all three files able to see each other, and it's not clear how to do this from those examples. I've also seen this, but again, this appears to be running an EXE that is "beside" the .net code, not embedded within it.
So, is there a way to run the EXE/DLL/supporting file "in situ"? Are the Assemblies ultimately a directory structure where I can run the EXE? And if so, how does one find/refer to these files?
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
I have installed OpenERP 6.1 software and now i want to connect it to a fiscal printer. There are some files I got from the vendor of the fiscal printer which are .dll files. The fiscal printer should communicate through the serial port. As per the vendor these files should be incorporated in the source code of the program one is building. These files are .net files. Is there any way the program should communicate with the fiscal printer without using those .dll files?
Any idea on how to integrate the printer and the program will be highly appreciated.
Depending on what you want to print on that printer, you could try the following:
Write a .NET service that monitors a directory for text files. When a file is written to the directory, print its contents and delete the file. Then make OpenERP write files into that directory when you want to print something.
Use some interop tools to communicate directly from Python to .NET. I haven't used it, but Python for .NET sounds promising. You could also try some COM interop and write a wrapper for those libraries that exposes them via COM.
Figure out what the actual interface is for the printer, and write to the serial port from Python.
Configure the printer as a regular Windows printer, and then print the regular PDFs that OpenERP generates for reports. I'm not sure whether that's possible with your printer.