Neue Testversion 20.40b12

[photoken]

Not here.

When I run the PhotoLineScriptD from the Scripts sub-menu, nothing happens. When I close the image and close PL, PL continues running as a background process. I must use Task Manager to kill it.

The same is true for the ExportWeb DLL that comes with PLbeta12.

Perhaps your development version of PL has some different code than the released beta12?

Also, why would your PhotoLineScriptD.DLL have an entry point but my DLLtest01.DLL not have one? The code defining the DllExport function seems to be the same and both were compiled with VS2017. Is there another hidden setting in VS that I'm missing when setting up the solution in VS?

[Gerhard Huber]

When I run the PhotoLineScriptD from the Scripts sub-menu, nothing happens.

PhotoLineScriptD and Export are the same. What they do, is nothing, when you have a document without "correct" layer names.

Also, why would your PhotoLineScriptD.DLL have an entry point but my DLLtest01.DLL not have one? The code defining the DllExport function seems to be the same and both were compiled with VS2017. Is there another hidden setting in VS that I'm missing when setting up the solution in VS?

the only thing I know, is that the nuget package has to be installed. I am no expert in such things. I installed it with the command line, like explaint on the web site of the package.

[photoken]

PhotoLineScriptD and Export are the same. What they do, is nothing, when you have a document without "correct" layer names.

But the layer name is "Jill".

the only thing I know, is that the nuget package has to be installed. I am no expert in such things. I installed it with the command line, like explaint on the web site of the package.

'I used the NuGet Package Manager "Manage NuGet Packages for Solution" GUI, and the DllExport package is listed as being installed for the solution. There is still the question of why one set of code does not create an entry point and the other solution does create an entry point.

Very confusing....

[Gerhard Huber]

PhotoLineScriptD and Export are the same. What they do, is nothing, when you have a document without "correct" layer names.

But the layer name is "Jill".

yes, "Jill" does nothing, because there is no filename.

the only thing I know, is that the nuget package has to be installed. I am no expert in such things. I installed it with the command line, like explaint on the web site of the package.

'I used the NuGet Package Manager "Manage NuGet Packages for Solution" GUI, and the DllExport package is listed as being installed for the solution. There is still the question of why one set of code does not create an entry point and the other solution does create an entry point.
Very confusing....

for me, too.
Perhaps I can find the problem, if you would send me your whole project.

[photoken]

But the layer name is "Jill".

yes, "Jill" does nothing, because there is no filename.

OK, now I understand how it should work, and the ExportWeb DLL does work here.

But, it leaves a PL background process running when PL is closed.

Here is what I did:

1. Open a JPG image.
2. Duplicate the background layer 3 times, naming those layers as shown:
   Jill layers.png
3. Run ExportWeb from the Scripts sub-menu.
4. Close the JPG image, answering "No" to the prompt to save it.
5. Close PL.

The result is that 3 new images are created in the directory of the original JPG, and they are named with the above layer names. However, PL cannot be launched again until I kill the PhotoLine background process that is still running.

[Gerhard Huber]

However, PL cannot be launched again until I kill the PhotoLine background process that is still running.

I think that's a problem of the current beta. We will fix it.

[photoken]

There is still the question of why one set of code does not create an entry point and the other solution does create an entry point.
Very confusing....

for me, too.
Perhaps I can find the problem, if you would send me your whole project.

I would very much appreciate that. Sorry to be such a pain....

The solution is attached.

[Gerhard Huber]

To avoid problems with scripts in dll format, the main function should look like this:

Code: Select all

		[DllExport("Main", CallingConvention = CallingConvention.Cdecl)]
		public static void Main()
		{
			try
			{
				Export();	// the function to call
			}
			catch
			{
			}
			GC.Collect();
		}

[Gerhard Huber]

I had a look on your project.
There is something missing about NuGet package "UnmanagedExports".
I removed the package from your project. Then quit Visual Studio. Start it again, open the NuGet console and write:
Install-Package UnmanagedExports -Version 1.2.7
After this, the package was installed here correct and the dll has now an entry point.

[photoken]

To avoid problems with scripts in dll format, the main function should look like this:
...

Yes, that makes sense -- I had to do something similar when writing an AddIn as a compiled Windows Forms executable. I found that I needed to call the Dispose() method of the form when closing the AddIn.

[photoken]

I had a look on your project.
There is something missing about NuGet package "UnmanagedExports".
I removed the package from your project. Then quit Visual Studio. Start it again, open the NuGet console and write:
Install-Package UnmanagedExports -Version 1.2.7
After this, the package was installed here correct and the dll has now an entry point.

Thank you very much for looking at this.

I will be working on getting a DLL working here, but I have a couple of questions right now:

• When you run the DLL, do you get a Windows form that displays the MessageBox when the "OK" button is clicked?
• If so, would you post your compiled DLL here, please?
• Are you using VS2015? I suspect that the UnmanagedExports 1.2.7 package does not work with VS2017. If my experiments prove that, then I'll need to try the newer DllExport package that is being maintained by "3F"....

[Gerhard Huber]

When you run the DLL, do you get a Windows form that displays the MessageBox when the "OK" button is clicked?

I select the entry in the menu. The message box appears, I click OK and it disappears.

If so, would you post your compiled DLL here, please?

I append it.

Are you using VS2015? I suspect that the UnmanagedExports 1.2.7 package does not work with VS2017. If my experiments prove that, then I'll need to try the newer DllExport package that is being maintained by "3F"....

I tried it with both versions of Visual Studio. Both work the same way here. I have 1.2.7 and there is no problem on VS2017.

[photoken]

I tried it with both versions of Visual Studio. Both work the same way here. I have 1.2.7 and there is no problem on VS2017.

OK, thank you very much, again! Also, thanks for the compiled DLL.

This gives me some hope that I can somehow get the DLL thing working....

[photoken]

This gives me some hope that I can somehow get the DLL thing working....

I give up.

The compiled DLL you posted here works as you described.

So, I created a new Class Library project, used the NuGet console to install the UnmanagedExports 1.2.7, copied the Form1.cs code to this new project, and compiled it for the x64 platform. The &$@$# thing does nothing when run from PL.

Ahhhhh!
I found the problem -- I do all my work on this computer while logged in as a Standard User account. When running VS2017 in that account, the NuGet console shows that the UnmanagedExports package was installed (and VS2017 uses its methods as expected), but the UnmanagedExports installation is actually half-assed.

The solution is to run VS2017 as an administrator. UnmanagedExports installs properly, and compiling the code gives a DLL that does work.

Whew!

[photoken]

Just a quick update on my DLL experimentation --

• I'm using the DllExport tool maintained here:
  https://github.com/3F/DllExport
  because it seems that this is the exporting tool that will be maintained and updated, going forward.
• That tool automatically compiles x86 and x64 versions of the DLL.
• I figured out how to display the WinForm GUI in a DLL!

For anyone who's interested, here's the complete code for the Form1.cs. It can serve as a basic template for creating DLLs that need a GUI for user input:

Code: Select all

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Globalization;
using System.Linq;
using System.Resources;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace DLLMessageBox01 {
	public partial class Form1 : Form {

		public Form1() {
			InitializeComponent();
		}

		[DllExport("Main", CallingConvention.Cdecl)]
		static void DisplayGUI() {
			Form1 GUIForm = new Form1();
			GUIForm.Show();
		}

		static void ShowMessage() {
			string message = "Hello World!\n(again)";
			string titletext = "Test";
			MessageBox.Show(message, titletext, MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
		}

		public static void CloseAddin() {
			Form1.ActiveForm.Dispose();
		}

		private void buttonOK_Click(object sender, EventArgs e) {
			try {
				ShowMessage();
			} catch (Exception appe) {
				MessageBox.Show(appe.InnerException.ToString(), "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
				throw;
			} finally {
				CloseAddin();
			}
		}
	}
}

And I've attached the compiled DLL to demonstrate its behavior.