and again dll and market - page 3

[Nikolai Karetnikov]

Roman:

So you are the ones preparing an article on the voice engine?
How's it going, will the article be published?

I sent a draft to Renat, so far no word)

[Nikolai Karetnikov]

Реter Konow:
Through resources. This is how I did it.

Can you tell me more about it?

I don't understand about winapi either. In my case I need function CopyFileW fromkernel32.dll and function ShellExecuteW from shell32.dll

I can't find analogues in <winapi\fileapi.mqh>.

[Alexsandr San]

Nikolai Karetnikov:

Can you tell me more about it?

I don't understand about winapi either. In my case I need function CopyFileW fromkernel32.dll and function ShellExecuteW from shell32.dll

I can't find analogues in <winapi\fileapi.mqh>.

Here is an article aboutCopyFileW functionhttps://www.mql5.com/ru/articles/2552

CopyFileW- copies files to and from the MQL5 sandbox.

[Maxim Kuznetsov]

I don't understand, is he writing an article for the website or a product for the market?

the articles and source code attached to them are obviously WinAPI admissible, it's popularization of the terminal's capabilities

"maybe the editorial board will have a quick look to see if calls are used for something bad and can be done without them.

But for the marketplace, #import "dll-name" will definitely not work.

[Реter Konow]

Nikolai Karetnikov:

Can you tell me more about it?

I don't understand about winapi either. In my case I need function CopyFileW fromkernel32.dll and function ShellExecuteW from shell32.dll

I can't find analogues in <winapi\fileapi.mqh>.

Anyway, there is such a thing as resources. Read more about it in documentation. Besides connection of files and pictures from outside, mql-program can write data to internal resources at runtime and this data can be visible to other program on other graph, if other program "knows" path to first program's resource. This way both programs can "communicate" - exchange data at up to 16ms.

Essentially, the resources can be used as shared memory for programs.

If the first (marketed) program handles the resources and the second (open) program reads them and calls the dll, then the problem is solved.

But, marketplace rules prohibit creating external product dependencies. If there is an option instead of a dependency, then maybe.

[Nikolai Karetnikov]

Alexsandr San:

here is an article aboutCopyFileW functionhttps://www.mql5.com/ru/articles/2552

CopyFileW- copies files to and from MQL5 sandbox.

it's surrealistic ))

The article describes calls from system dlls imported into code. In my code this is exactly what is happening in the code.

After this post

Alexey Volchanskiy:

Underlined phrase can you decode it? )) I made wrappers for most Win API functions a long time ago. You may use them in the Market. I asked Renat for details.

\MQL5\Include\WinAPI\...

I assumed that with the help of winapi libraries you may avoid the need to directly access the DLL, and hence avoid the need to link DLL to the code and, hence, be able to display code with winapi functions in the Market.

Was I wrong?

[Roman]

Nikolai Karetnikov:

Was I wrong?

Yes, all WinApi calls from Mql are made after linking system Dlls.
Windows functions are called from these Dlls.

[Nikolai Karetnikov]

Maxim Kuznetsov:

I don't understand, is he writing an article for the website or a product for the market?

the articles and source code attached to them are obviously WinAPI admissible, it's popularization of the terminal's capabilities

"maybe the editorial board will have a quick look to see if calls are used for something bad and can be done without them.

but for the marketplace, #import "dll-name" will not work.

the article might be about the basic version of the product

[Реter Konow]

Nikolai Karetnikov:

...

Was I wrong?

Give it a try. Trying, as they say, is not torture).

Then, tell me here whether it worked or not.

[Nikolai Karetnikov]

Реter Konow:
Anyway, there is such a thing as resources. Read more in the documentation. In addition to connection of files and pictures from outside, mql-program can write data to internal resources at runtime and this data can be visible to other program on other graphics, if other program "knows" path to resource of first program. This way both programs can "communicate" - exchange data at up to 16ms.

Essentially, resources can be used as shared memory for programs.

If the first (market) program handles the resources and the second (open) program reads them and calls the dll, then the problem is solved.

But, marketplace rules prohibit creating external product dependencies. If there is an option instead of a dependency, then maybe.

Would the Market Advisor be able to write a text file as a resource?

Then I would form the file with closed code, and change the extension with open code and play it back