How can I find in Visual C++ if an OCX file (for example flash.ocx) is registered or not?
If you mean from the .ocx file itself, you've probably got two options:
Read the type library from the .ocx, parse out the object and interface UUIDs and see if they all exist in the registry under HKCR\CLSID, HKCR\TypeLib etc.
Loop through all registered objects in the HKCR\CLSID in the registry and see if any of them reference your .ocx as their InprocServer32 reference. You may need to do path and environment variable expansion on the path you read in order to test the match.
The first method won't necessarily tell you if it's the same version of the .OCX installed, though (although you can check the path on disk for each). The second is unfortunately going to be very slow.
It's probably simplest to just re-register the .ocx I'd think.
You can check if the clsid of the ocx is under HKEY_CLASSES_ROOT.
Here is a simple code I use to detect on runtime to check if a specified ocx is registered.
#include<windows.h>
...
//Check if an ocx is resisted, and push warning
HKEY subKey = NULL;
LONG ret = RegOpenKeyEx(HKEY_CLASSES_ROOT, _T("CLSID\\{XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX}"), NULL, KEY_QUERY_VALUE|KEY_WOW64_32KEY, &subKey);
//Note that some CLSID of versioned ocx is under HKEY_CLASS_ROOT\TypeLib\{XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX}
if(ret != ERROR_SUCCESS)
{
TCHAR message[512];
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM,NULL,ret,0,message,512,NULL);
CString msgStr = message;
#ifdef DEBUG //Extra message on DEBUG mode
AfxMessageBox(msgStr.GetBuffer());
#endif
AfxMessageBox(_T("OCX not registered"), MB_OK);
}
else
{
AfxMessageBox(_T("OCX is registered"), MB_OK);
RegCloseKey(subKey); //Remember to close opened key handle.
}
Related
I'm trying to open and write to a file using Dart's IO library.
I have this code:
File file = File("text.txt");
RandomAccessFile raf = file.openSync();
raf.writeStringSync("A string!");
Now when doing this I get the following error in the console:
(OS Error: Access is denied., errno = 5)
So file is not opened for writing, and I'm looking here: open method, and can't figure out how to use open or openSync to get RandomAccessFile I can write to.
It says I need to use write constant to do that but just can't figure out how?
If I try to create FileMode and add it to open method as an argument I get an error saying:
Error: Too many positional arguments: 0 allowed, but 1 found.
So open and openSync methods can't take any arguments, how would one use FileMode, and open method to open a file that is ready for writing? So I need to get RandomAccessFile that is in writing mode? And by default its only in read mode? I'm not trying to use writeString or writeStringSync, I know those methods exist, but I'm interested in how is this done using open and openSync methods that return RandomAccessFile!
Update:
You are getting this error:
Error: Too many positional arguments: 0 allowed, but 1 found.
because the openSync method has no positional arguments, but just one named parameter (mode).
So to fix your code you must add it:
RandomAccessFile raf = file.openSync(mode: FileMode.append); //Or whatever mode you'd to apply
Having said that, there are several other ways to write to a file, most of them listed in the docs:
writeString or writeStringSync, I'd suggest these if what you need is just to write once to a file.
openWrite, which returns a Stream that can be written in order to write to the file.
(All of these methods have a FileMode mode named parameter)
I'm using the Microsoft.Office.Interop.Excel library (version 14.0) from an F# application and I can't seem to be able to reference some of the properties defined in Interop's interfaces/classes.
For example, if I have a Worksheet object I can't do the following:
let sht = // Get the Worksheet
sht.PageSetup.CenterHeader <- // Set the header
It can't find CenterHeader as a property of the PageSetup interface, even though it's there if I view the Interop dll in the object browser.
Just for reference, the Interop dll that I'm using is from the VS directory: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Visual Studio Tools for Office\PIA\Office14\Microsoft.Office.Interop.Excel.dll
Update:
I actually spoke too soon. Unfortunately the suggested solution with the cast didn't work either. VS thinks it's OK but it fails at runtime with the following error:
Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.Office.Interop.Excel.IPageSetup'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{000208B4-0001-0000-C000-000000000046}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
As I said in the comments, F# doesn't support type equivalence for embedded interop types, so if a C# project has Embed Interop Types enabled then the F# compiler may be unable to determine which version of the interop type to use. Since the type embedded in the C# output assembly has been stripped down to only the members used, this can make it so that the F# compiler is unable to see members that are present in the version of the type from the primary interop assembly.
The workaround is to turn off Embed Interop Types on the C# project.
This works for me:
#if INTERACTIVE
#r "office"
#r "Microsoft.Office.Interop.Excel"
#endif
open Microsoft.Office.Interop.Excel
let setCenterHeader fileName worksheet header =
let file = System.IO.FileInfo(fileName)
let excel = ApplicationClass()
try
// Make sure to use full path since this will
// be interpreted as relative to Excel's process,
// not currently executing one
let workbook = excel.Workbooks.Open(file.FullName)
let sheet = workbook.Worksheets.[worksheet] :?> Worksheet
sheet.PageSetup.CenterHeader <- header
workbook.Save()
finally
excel.Application.Quit()
setCenterHeader "TestWorksheet.xlsx" "Sheet1" "My header 1"
setCenterHeader "TestWorksheet.xlsx" "Sheet2" "My header 2"
setCenterHeader "TestWorksheet.xlsx" "Sheet3" "My header 3"
You might want to make sure you have matching versions of PIA and Office installed/used.
I have application that contain statically linked lua 5.2 inteperpreter (and haven't access to code).
When I trying to write extension with next code:
#define LUA_LIB
#define LUA_BUILD_AS_DLL
#include "lua.hpp"
extern "C"
{
static int test(lua_State* state)
{
return 1;
}
static const struct luaL_Reg functions[] = {
{"test", test},
{NULL, NULL},
};
int __declspec(dllexport) luaopen_test(lua_State* state)
{
luaL_newlibtable(state, functions);
luaL_setfuncs(state, functions, 0);
return 0;
}
}
And compile it with statically linked lua52.lib .
I get "multiple vms detected" error when I trying to require it fromn lua code.
What I can do in this situation?
You can't compile it with statically linked lua52.lib as the main application loads its own version of lua52.lib and when this module is "required", it loads its own copy, which leads to "multiple VMs detected" message.
With statically compiled VM you have two options (on Windows): (1) include all your modules statically, or (2) compile your modules against Lua52.dll, but instead of the actual DLL include a "proxy" DLL that will forward Lua API calls to the methods in the statically compiled executable (the API methods also need to be exported in the executable).
See this thread for the discussion on how the executable needs to be compiled and LuaProxyDllFour page for the proxy DLL.
On Linux you don't need to have a proxy library, but you still need to avoid linking Lua interpreter into the library and export symbols from the executable by using -Wl,-E linker option; see lhf's answer for details.
I am developing an ADO application (32 bit) on Windows 7 64 bit SP1 (all updates installed): The app must run on Win XP. According to http://support.microsoft.com/kb/2517589/en-us I am using msado60_backcompat. That worked well until lately, but now it crashes.
My code (snippets):
_CommandPtr cmd(__uuidof(Command));
cmd->ActiveConnection = dbconn;
cmd->CommandText = _T("SELECT [si] FROM [TTable] WHERE [TTable].[ti1]=?");
cmd->Parameters->Append(cmd->CreateParameter(L"#ti1", adTinyInt, adParamInput, 1, 7));
CreateParameter is implemented in msado60_backcompat:
inline _ParameterPtr Command15::CreateParameter ( _bstr_t Name, enum DataTypeEnum Type, enum ParameterDirectionEnum Direction, ADO_LONGPTR Size, const _variant_t & Value )
{
struct _Parameter * _result = 0;
HRESULT _hr = raw_CreateParameter(Name, Type, Direction, Size, Value, &_result);
if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
return _ParameterPtr(_result, false);
}
raw_CreateParameter() calls into msado15.dll into CCommand::CreateParameter. There a crash occurs at offset 0x34f (offset inside the function):
First-chance exception at 0x655ed5a6 (msado15.dll) in adosqlbugcheck.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Unhandled exception at 0x655ed5a6 (msado15.dll) in adosqlbugcheck.exe: 0xC0000005: Access violation writing location 0xcccccccc.
Msado60_Backcompat.tlb: 73728 bytes, 29.4.2011
msado15.dll: 6.1.7601.17514, 1019904 bytes, 21.11.2010
The error does not occur if I use msado15.dll.
Can someone reproduce the error? Is there a solution?
The issue is solved. I was #import-ing the msado60_backcompat.tlb from "C:\Program Files\Common Files". If I import the version from "C:\Program Files (x86)\Common Files" it works. The compiler generates tlh files from both tlb files with exactly the same UUIDs and everything else, they only differ in that the one contains
typedef __int64 ADO_LONGPTR;
typedef ADO_LONGPTR PositionEnum_Param;
While the other contains
typedef long ADO_LONGPTR;
typedef enum PositionEnum PositionEnum_Param;
From my understanding of COM interfaces this should not happen. But since MS commits they really made a mistake it seems to just be the way it is.
Just for information, MS has a new solution coming up: http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx.
We have a lot of Delphi Projects, when I build them before, I didn't see any error. But recently I see the following error when I build one of those projects.
D:\Delphi Projects\MySetting.pas Fatal: Could not compile used unit 'mscorlib_TLB.pas'
At first I thought some background process is using this mscorlib_TLB.pas, then I restart my computer and build it again, it still fails and gives the same error above. What is this mscorlib_TLB.pas error?
Thanks!
You have imported a COM object that is COM Callable Wrapper (CCW) around a managed (.net) object. The imported type _TLB.pas file will (sometimes needlessly) have a reference to mscorlib_TLB in its uses clause.
Delphi's type-library importer is buggy, and there are syntax errors in the auto-generated TLB pas file.
Try removing references to mscorlib_TLB in whatever unit is using it.
If the unit actually depends on something in mscorelib, then you'll have to manually fix the syntax errors in the 400kB pas file.
If you really need to use the library, you can import it using the Component::Import Component tool.
I found mscorlib_TLB alongside a COM wrapper that I built in C# a few years ago, MyComWrapper. When I copied MyComWrapper_TLB to another workstation, it was also necessary to copy mscorlib_TLB since it included type definitions required by MyComWrapper_TLB.
A re-import of the related tlb should regenerate mscorlib_TLB.pas if it can't be found. It appears I reimported the tlb on Oct 4, 2017.
Here's the prologue describing the unit:
unit mscorlib_TLB;
// ************************************************************************ //
// WARNING
// -------
// The types declared in this file were generated from data read from a
// Type Library. If this type library is explicitly or indirectly (via
// another type library referring to this type library) re-imported, or the
// 'Refresh' command of the Type Library Editor activated while editing the
// Type Library, the contents of this file will be regenerated and all
// manual modifications will be lost.
// ************************************************************************ //
// $Rev: 52393 $
// File generated on 10/4/2017 11:15:21 PM from Type Library described below.
// ************************************************************************ //
// Type Lib: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.tlb (2)
// LIBID: {BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}
// LCID: 0
// Helpfile:
// HelpString: mscorlib.dll
// DepndLst:
// (1) v2.0 stdole, (C:\Windows\SysWow64\stdole2.tlb)
// Parent TypeLibrary:
// (0) v1.0 MyComWrapper, (C:\source\my-client\client-project\MyComWrapper\bin\x86\Release\MyComWrapper.tlb)