Adobe ExtendScript ExternalObject on 64 bit windows - adobe-indesign

I'm trying to create an ExtendScript DLL library to load with the ExternalObject function.
It works great with InDesign versions that are 32 bit. However on a 64 bit version of InDesign CC on Windows it fails to load.
Setting ExternalObject.log = true only results in "ExtObj: load error!" message.
I'm trying to even get the sample projects "BasicExternalObject" and "SampleLib" to run and can't get those running.
I'm running Visual Studio 2015 Community Edition.
Thanks in advance for any pointers.

I was able to resolve this. It was a combination of issues.
Make sure all included libraries are compiled with same compiler settings for library. I used multi-threaded static.
See item 1 - make sure you don't have any dependency issues that require installing VS 2015 run-time libraries.
Need to have a version of the DLL for x64. The ExtendScript code needs to detect that environment and load the proper version.
var isWin = (File.fs == "Windows");
var libFilename = (isWin) ? "HttpLib.dll" : "HttpLib.framework";
if (isWin && ($.os.indexOf("64") > 0)) {
// we're on a 64 bit OS - see if the program path is in the 64 bit path
if (app.filePath.fsName.indexOf("x86") == -1) { // looks like we're 64 bit then
libFilename = "HttpLib64.dll";
}
}
use ".fsName" before loading - it was failing on directories that had spaces in the path.
var libPath = File($.fileName).parent.fsName + "/" + libFilename;
var httpLib = new ExternalObject("lib:" + libPath);

In Visual Studio, you need to compile and build for x64 platforms. You can do this by going to the dropdown under Visual Studio's main menu bar and selecting x64.
Of course, you will need to make sure your project properties are setup correctly for x64 platform. You can do that by right-clicking your project name in the "Solution Explorer" panel and then clicking on "Properties..." When the dialog comes up, make sure the dropdown at the top is set to x64.

Related

Properties of richtextbox control cannot be set

On one computer 'A' (win vista 32 bit) if I run my program in debug mode all the richtextbox controls throw 'property cannot be set' errors.
I can go on to build the exe (without error ) and the full application OK
But when I then install and run the application on this computer or on computer 'B' (win xp) the same problems occur on both.
However if I run the exact same code in debug mode on computer 'B' there are no errors.
If I build and install the application on computer 'B' it works fine. If I then install this application on computer 'A' it also works fine.
When putting together the application for distribution, both computers use identical copies of richtx32.ocx (it, like the code, is checked out from the same repository).
If I check out previous copies of the code on computer'A' (that used to previously behave OK) they also now exhibit the same problems as the latest version of the code.
I don't have a clue what's going on, please help!
I'm seeing multiple references to the Property cannot be set message being resolved in the version of the Rich Text Control that is distributed in Visual Studio 6.0 Service Pack 4, and another Property cannot be set message fixed in SP5.
First and foremost, make sure that a minimum of SP5 is installed; I'd just go with SP6.
For reference, my Microsoft Rich Textbox Control 6.0 (SP6) is at C:\Windows\System32\RICHTX32.OCX, and is version 6.1.97.82.
I know you said that both machines have the same copy of the control installed; for the sake of completeness, you may want to double-check that the new control was registered after installation.
EDIT:
I exported the HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402} reg key:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}]
#="Microsoft Rich Textbox Control 6.0 (SP6)"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Control]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A52-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A53-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{0DE86A57-2BAA-11CF-A229-00AA003D7352}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED4-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{40FC6ED5-2438-11CF-A3DB-080036F12502}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\InprocServer32]
#="C:\\Windows\\system32\\RICHTX32.OCX"
"ThreadingModel"="Apartment"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus]
#="0"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\MiscStatus\1]
#="131473"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ProgID]
#="RICHTEXT.RichtextCtrl.1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\ToolboxBitmap32]
#="C:\\Windows\\system32\\RICHTX32.OCX, 1"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\TypeLib]
#="{3B7C8863-D78F-101B-B9B5-04021C009402}"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\Version]
#="1.2"
[HKEY_CLASSES_ROOT\CLSID\{3B7C8860-D78F-101B-B9B5-04021C009402}\VersionIndependentProgID]
#="RICHTEXT.RichtextCtrl"
A bad richtx32.oca file in the system32 directory seems to have been the cause of this.
Here's what an .oca file does:
Some of the properties of the control are provided by the framework
and some by the control itself. Programmatically, the properties from
the framework and the control all appear as properties of the control.
In order for these properties to appear, Visual Basic creates an
extended type library when the control is loaded into the toolbox.
Because the process of reading the control's type library and creating
the extended type library is time consuming, Visual Basic caches the
extended type library information into an OCA file.
If you delete the OCA file for a control Visual Basic recognized,
Visual Basic will recreate the .OCA file when you load a project
requiring the control. This recreation process comes with a time
penalty.
So it seems that having a bad .oca file in existence can mean that the properties of the control both in the IDE and in the compiled .exe will be affected.
The solution is to delete the .oca file in the system32 folder and then load the project again.

How Can I Add an "ATL Simple Object" to Old ATL DLL Project Upgraded to VS 2010?

We have a DLL project which has existed for a long time (maybe as far back as Visual Studio 6) which has been updated for each new version of VS. The project contains a number COM classes implemented using ATL.
After upgrade to VS 2010, the project still builds fine. However, if I try to right-click the project and choose Add -> Class... -> ATL Simple Object, I get an error box that says this:
ATL classes can only be added to MFC EXE and MFC Regular DLL projects or projects with full ATL support.
This worked in VS 2008.
When I look at the project properties, Use of MFC was set to Use Standard Windows Libraries and Use of ATL was set to Not Using ATL. I changed these to Use MFC in a Shared DLL and Dynamic Link to ATL respectively, but still get the same error.
I know how to add new ATL objects without using the wizard, and I could try to recreate the project from scratch using VS 2010 to make it happy. But does anyone know of any easy way to get VS to allow me to use the ATL Simple Object wizard with a project that it doesn't recognize as a project "with full ATL support"?
Check this thread out.
It seems that adding this fragment info your ATL C++ code make it work. You don't need to actually build the project, just remove this stuff away after you are done with the wizard (provided that solution works for you).
// Added fake code begins here
class CAppModule :
public CComModule
{
};
// Added fake code ends here, below is regular ATL project stuff
CAppModule _Module;
This is where it all comes from, in $(VisualStudio)\VC\VCWizards\1033\common.js:
/******************************************************************************
Description: Returns a boolean indicating whether project is ATL-based.
oProj: Project object
******************************************************************************/
function IsATLProject(oProj)
{
try
{
var oCM = oProj.CodeModel;
oCM.Synchronize();
// look for global variable derived from CAtlModuleT
var oVariables = oCM.Variables;
for (var nCntr = 1; nCntr <= oVariables.Count; nCntr++)
{
var oVariable = oVariables(nCntr);
var strTypeString = oVariable.TypeString;
if (strTypeString == "ATL::CComModule" || strTypeString == "ATL::CAutoThreadModule")
{
return true;
}
Same problem here, but the project source already had CComModule _Module;
Fixed it, based on the IsATLProject script shown above, by changing it to
**ATL::**CComModule _Module;

gtk app cant see windows path value to use gtk+ dlls

I added c:\_hub\gtk\bin to windows path var, and still when I try to run gtk app, it shows me an error about missing dll. if I will put my app to c:\_hub\gtk\bin, it will run.
any ideas?
I use codeblocks. created project in this way: file > new > gtk+ app
Wizard asked me to show gtk dir, I pointed him to gtk dir. then wrote
a simple -> build.
as you can see, I didnt add any compiler params etc
The problem was that was using Total commander and when I changed enviroment variables in windows, it wont change in Total commander session. So I had to close total commander, change enviroment and then everything was ok.

Why is Interop.WMPLib unable to load assembly in Release mode, but works in Debug mode?

I have added the Windows Media Player com control into my toolbox and then used the control successfully on a Form in Debug mode.
However, when I try running the application in Release mode it errors with...
Could not load file or assembly
'Interop.WMPLib, ... or one of its
dependecies. An attempt was made to
load a program with an incorrect
format.
Through some tracing I've established that the error occurs not when creating the control but on the EndInit method.
Public Sub New
InitializeComponent()
wmp = New AxWMPLib.AxWindowsMediaPlayer()
wmp.BeginInit()
wmp.Enabled = True
wmp.Name = "wmp"
wmp.OcxState = CType(resources.GetObject("wmp.OcxState"), AxHost.State)
Me.Controls.Add(wmp)
Me.Controls.SetChildIndex(wmp, 0)
wmp.Dock = System.Windows.Forms.DockStyle.Fill
wmp.EndInit() ' <<< errors here !
End Sub
What am I missing?
You changed the Platform target setting in the Debug configuration. Possibly weeks ago, maybe even in a previous version of Visual Studio. But didn't change it in the Release configuration. It is one of the settings that is configuration specific.

Blank text editor in Vis Studio

I have just installed VS 2005. I created a project. I added code to the project and then debugged the code. The program ran ok. I save the project. Everything saves fine. I go to open the project and the text editor is blank, or so it appears. After further investigation I notice that the code is there but I just can't see it. I debug and the program runs but no code can be seen. Strange. What is additonally weird, is I have installed the python idle and it to is blank, no code to be seen. However, the code is in there because I can run the code. I have adjusted just about every display property in VS as well as the os display props. I am using a Dell Latitude M60 Laptop, w/ windows xp professional, sp2, intel pentium M, 2 Ghz, 1gb ram. What do you think? Any body have this happen to them?
Could it be.. Right_Mouse+Click on the file in the Solution Explorer and chose "View Code"?
sometimes windows needs a restart :-)

Resources