Believe it or not, for as long as I've worked with VO, and now X#, I've never had any occasion to open a DLL within a VO application. In connection with a more simplified web-based application, a friend suggested that I separate code for one application into two parts: the code for the UI, and the program logic. That's a good idea, because it provides me just one place where I can develop and debug for both the local and web-based apps, and for as big as it is, helps immensely with organization. So I copied code for the latter to specifically create the DLL.
The problem is that I don't know how to open or access the DLL at the start of runtime. I looked around the forum for a clue, but didn't find it. When I looked through my old VO Help file, it advised me to look through the Programmer's Guide, which I no longer have.
Opening a DLL
Opening a DLL
Hi Thomas,
if you build a DLL in VO, the compiler builds an AEF file, and you can import that in your VO repository and add it in the libraries of your application.
Wolfgang
if you build a DLL in VO, the compiler builds an AEF file, and you can import that in your VO repository and add it in the libraries of your application.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Opening a DLL
Hi Thomas,
IMHO using a DLL in VO is relatively inefficient because (specially on large DLLs with many classes) it uses more memory at runtime, needs more time to start and may impose some reorganziations. For example, you cannot add the same library to both your DLL and the calling executable.
In X# the game changes completely, there DLLs are the way to go.
Wolfgang
IMHO using a DLL in VO is relatively inefficient because (specially on large DLLs with many classes) it uses more memory at runtime, needs more time to start and may impose some reorganziations. For example, you cannot add the same library to both your DLL and the calling executable.
In X# the game changes completely, there DLLs are the way to go.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
-
ThomasWYale
- Posts: 43
- Joined: Thu Jun 20, 2019 5:19 pm
Opening a DLL
I understand. I don't intend to use the DLL in the VO application, nor in its X# counterpart, but rather a web-based application that uses the program logic. Separating the code between the modules responsible for the UI and the program logic was to build a web-based application to translate single sentences in English into Spanish. The main application does that already, but the web-based application would have just two textboxes, one for user to enter the English sentence, and the other to display the Spanish translation, and use the program logic in the DLL.
One other issue that you may be able to clear up for me: depending on the nature of the English sentence, the local application may pause processing and request additional user input to complete the analysis. This it does by constructing and displaying various dialog windows for the user to enter. But if a web-based application uses a DLL that has no libraries to construct and display those windows in those cases (and that's merely assuming that GUI Classes library couldn't be included in a DLL to display in a web-based application), no additional user input can be provided and analysis can't continue. An IT friend suggested that I treat those cases as errors, but that will just produce the same result. For those particular sentences, it simply wouldn't work. It's somewhat analogous to needing to ask a question but having no vocal cords. Would there be some way to overcome that obstacle?
One other issue that you may be able to clear up for me: depending on the nature of the English sentence, the local application may pause processing and request additional user input to complete the analysis. This it does by constructing and displaying various dialog windows for the user to enter. But if a web-based application uses a DLL that has no libraries to construct and display those windows in those cases (and that's merely assuming that GUI Classes library couldn't be included in a DLL to display in a web-based application), no additional user input can be provided and analysis can't continue. An IT friend suggested that I treat those cases as errors, but that will just produce the same result. For those particular sentences, it simply wouldn't work. It's somewhat analogous to needing to ask a question but having no vocal cords. Would there be some way to overcome that obstacle?
Opening a DLL
Hi Thomas,
I must admit I have never used VO DLLs in a non-VO application (with one exception: sometimes in the past Robert has given me a VO DLL to be used in X#, but that is already in the family).
When using a VO application in a non VO application you must make sure that the VO runtime is also correctly loaded and initialized. When the host application is a VO application, that is done correctly, but for non VO applications that must be done manually.
What is the language your VO DLL should be used with?
If it is a .NET application, then I would use X# to build the DLL, and then it can be used directly in the C#/VB.NET application.
You know that you can share source code also between X# and VO?
Wolfgang
I must admit I have never used VO DLLs in a non-VO application (with one exception: sometimes in the past Robert has given me a VO DLL to be used in X#, but that is already in the family).
When using a VO application in a non VO application you must make sure that the VO runtime is also correctly loaded and initialized. When the host application is a VO application, that is done correctly, but for non VO applications that must be done manually.
What is the language your VO DLL should be used with?
If it is a .NET application, then I would use X# to build the DLL, and then it can be used directly in the C#/VB.NET application.
You know that you can share source code also between X# and VO?
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
-
ThomasWYale
- Posts: 43
- Joined: Thu Jun 20, 2019 5:19 pm
Opening a DLL
The VO DLL will be used in a web application written in Python, using Flask to build the UI. I'll copy the code used in the DLL to a separate project in X# and build it that way, though would there be a difference in the DLL whether VO or X# is used to build it? And yeah, I know that source code can be shared between VO and X#.
Opening a DLL
Thomas,
If you create the DLL with VO then you need to access it using the .Net "PInvoke" mechanism. I am not familiar with Flask, but if would be the same as when you were accessing something from User32 or Kernel32. Make sure you only use standard Win32 datatypes for the parameters (so no Date, String, Float etc).
If you create the DLL with X# then it becomes a normal .Net assembly. Functions will become part of a compiler generated functions class. But it is probably easier to create static methods in a static class yourself, since that gives you full control over the class name. If flask is also based on .Net then you can use all .Net datatypes. You can also use X# specific datatypes (such as Date, Float, Usual etc) but you have to be aware then that these datatypes are implemented as special structures or classes with names such as XSharp.__Date and XSharp.__Usual.
Robert
If you create the DLL with VO then you need to access it using the .Net "PInvoke" mechanism. I am not familiar with Flask, but if would be the same as when you were accessing something from User32 or Kernel32. Make sure you only use standard Win32 datatypes for the parameters (so no Date, String, Float etc).
If you create the DLL with X# then it becomes a normal .Net assembly. Functions will become part of a compiler generated functions class. But it is probably easier to create static methods in a static class yourself, since that gives you full control over the class name. If flask is also based on .Net then you can use all .Net datatypes. You can also use X# specific datatypes (such as Date, Float, Usual etc) but you have to be aware then that these datatypes are implemented as special structures or classes with names such as XSharp.__Date and XSharp.__Usual.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
-
ThomasWYale
- Posts: 43
- Joined: Thu Jun 20, 2019 5:19 pm
Opening a DLL
I'll go over what your reply in more detail. In the meantime, something strange has happened. I used VOXPorter to convert the AEF comprising the DLL with the default options and it produced an *.sln and *viproj files. Neither of those is of a file type *.xiapp or *.viapp from which to import to X#. I'm certain that I did the same for my main application and had no problem. I don't understand what happened to change the file type.
Opening a DLL
Hi Thomas,
in the VOXPorter you need to check also the "XIDE" or the "both" option, but in your case, as you don't use Visual Studio, "XIDE" may be better:
Wolfgang
P.S. about integrating foreign DLLs in Python code, I found this link:
https://stackoverflow.com/questions/252 ... rom-python
in the VOXPorter you need to check also the "XIDE" or the "both" option, but in your case, as you don't use Visual Studio, "XIDE" may be better:
- XPorterScreen.png (50.85 KiB) Viewed 841 times
P.S. about integrating foreign DLLs in Python code, I found this link:
https://stackoverflow.com/questions/252 ... rom-python
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Opening a DLL
Hi Thomas,
.
The .sln file is used for VS, you just double click on it and it will open the ported app in VS. Same for the .viproj file for XIDE, you can double click on it, select XIDE as the default app to open this file type and it will open in XIDE. The .xiapp/.viapp files are only needed in order to add the ported app inside an already existing project of XIDE, and those can be found inside the directory of each ported app/library.ThomasWYale wrote:I'll go over what your reply in more detail. In the meantime, something strange has happened. I used VOXPorter to convert the AEF comprising the DLL with the default options and it produced an *.sln and *viproj files. Neither of those is of a file type *.xiapp or *.viapp from which to import to X#. I'm certain that I did the same for my main application and had no problem. I don't understand what happened to change the file type.
.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu