Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
i have a DLL and main application .
in the main application i create a form from DLL on panel owned by main application main form , the main form has other components (buttons) .
the problem:
when i press key (enter or tab) in DLL form components (edits) the main application main form takes the key and the button on main form click event executed .
The problem is that you have two distinct VCL instances in your application. One in the main program, and one in the DLL. That is not supported, and it is expected that much functionality does not work.
For instance, type identity does not behave the way you expect. Each module has its own separate versions of the VCL types. So, the executable's TPanel is distinct from the DLL's TPanel and so on. You can run into serious problems when you pass objects between executable and DLL because you can call methods from DLL on an object from the executable, and vice versa.
The supported way to do what you need is to use runtime packages instead of DLLs. That results in all modules sharing a single instance of the VCL.
If you don't want to use runtime packages then you should merge the DLL and the executable into a single executable module.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I need to create a .jar file out of few .so files using perl scripts
This is not generally possible.
A .so (shared object) is a library that can be loaded dynamically, like a .dll on Windows systems. These libraries contain natively compiled code, and may depend on other libraries in turn. A .jar is an archive for the Java Virtual Machine (JVM). It too can be loaded dynamically, but it contains .class files that contain code compiled for the JVM.
Which much hackery, you could perhaps translate a program in machine code to JVM byte code (or write an emulator e.g. for the x86 architecture), but it would be excessively difficult to do, as the execution model of a CPU and the JVM differ substantially, e.g. in their treatment of memory. The result would likely be highly inefficient. And re-compiling a dynamically loaded library would be rather unportable, thus defeating the purpose of the JVM.
If you simply want to interface with a native library from the JVM (e.g. a program written in Java), then you could use the Java Native Interface (JNI) instead. In that case, you'd have to write a C or C++ wrapper around the .so, and would then be able to call the functions.
I have no idea why you mentioned Perl. While a nice language, it cannot help here.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have a whole bunch of Eclipse projects, large and small, that I want to keep organized. I'm trying to figure out if there is some sort of property that can be attached to the project in order to provide a description of what the project is or what it was created to do or test. I would hope that this field can be easily viewed at the time you are browsing through a list of projects. It would be nice if I could put descriptive text into this field and not have to consider giving my projects names like 'TwitterOAuth2TestImplementationUsingScribe'
Anything that would allow you to browse your projects in a way similar to this (each line represents an Eclipse project):
Myproj1 Simple Test Project
LogTest3 Test new logging class
NetworkUDPTests Testing UDP classes
OAuth2Example Sample project for Oauth2
Unfortunately, project "description" is the name of the .project file that stores each project's settings, so it is a bit harder to search for information on this.
Thats an interesting question we also face. Currently there does not seem to exist a solution for this problem. The only thing that could come near to providing one is the Mylyn Intent project, as it aims to provide a comprehensive documentation on design decisions, which takes into account the inter-dependencies between plugins.
This inter-dependency is exactly the problem. There exist solutions to document the purpose of java packages which is limited to the classes however.
Our solution is a readme.textile embedded in the root of each plugin, providing this specific information. It would, however, be interesting to introduce the documentation used for packages for bundle documentation, which could be used to autogenerate an overview documentation.
There is a comment tag in the .project file: http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/reference/misc/project_description_file.html
However it looks like Eclipse itself doesn't use the content of this tag. I changed it manually but after that I've never seen the text I entered anywhere in Eclipse
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been developing iOS apps for about a year. In that time, I have developed a fair number of classes that I frequently recycle from app to app. For example, I have a bunch of classes related to making it easier to write table views to control in-app settings.
Right now, I simply grab these classes from one app and paste them into the next one. My question is -- at what point is it likely to be easier to create and use a static library?
Static libraries have their problems as well.
Using a static library discourages you from fixing problems as you see them, since the code is in another project and it becomes troublesome.
GCC has a bug in whereas any method defined in a category is optimized away from the static library. Not good if you library code consist of lots and lots of convenience categories on existing classes.
So what you want is a solution where you can add dependencies to actual source code. This way you avoid the nasty GCC bug, and the boy scout rule is encouraged!
Our solution is a simple dependency system based on Rake. It creates sym-links to the source code of the shared libraries, and hard copies when building on the build server (You should never build the distribution binaries on a developers own machine!).
The sym-links allow developers to edit the shared code just as if it was part of the current project, while ensuring any cleanups, bug-fixes, etc. are always propagated to a single repository and benefits all projects using the shared library.
The hard-copies on the build server allows for the shared libraries to be tagged for version, so that the exact build of v1.0 you sent to App Store is forever reproducible!
A colegue of mine have blogged about setting up a build server for continious integration here: http://blog.jayway.com/2010/01/31/continuos-integration-for-xcode-projects/
I will nag him to blog and share the Rake based dependency system as well. It is basically just a handful of lines with Ruby script.
I have my own library of miscellaneous stuff.
I add things to it that I deem to be reasonably generic and that I can envisage using in the future at some point.
After all, there's no harm in adding it to your library, even if you never use it again.
As soon as you tire of copying and pasting you should create a library. Or, as soon as you make your first mistake (mis-)copying and (mis-)pasting.
Or, in more business-like terms: when the net present value exceeds the net present cost.
If you want to distribute your classes out to your "team", then you will not have to worry about changes they make to your code, thus keeping the libary consistant.
Or if you wanted to sell your classes as API's to another DEV team then your can hide the source code from the API user.
I have a few "utility" classes that I find usuful and I do tend to drop the class file into my solution as I find it easier and quicker, (not that the extra 2 to 3 clicks matter), so really i suppose i do it out of habbit more than anything else.
Another solution is to use use a version control system (such as git) that supports submodules. You can wrap up each of these helper classes (or even a collection of classes) in its own repository which can be imported into the main repository of your code.
In this way you don't have to worry about cutting and pasting errors. Also, if you make improvements to these classes they can be propagated to other projects that use them (if you want to), yet you can always roll back to previous versions for bug fixing / testing.
It is common to find such helper code on sites such as github example
I have a static library that is in a separate project.
That way I can fully develop the library, complete with unit tests etc. and then simply re-use it by making another project dependant on it.
It means I don't have to cut/paste, and it also means that should I find/fix a bug, or add/modify a feature of the library, then it can be regression tested easily.
Now all the projects that use that library can benefit.
So for my money, the time to turn a collection of 'useful code' into a library is certainly when you find you want to use it again.
(Of course we all have useful code snippets we re-use by copy/paste from a previous project - those aren't necessarily right for being in a library.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Hey Folks, I need to create a plug-in that updates an application.
Look, I have a host application, but probably I will update it with to more functions. I am working in Windows with Delphi 7.
Basically, "my plugin" should add 2 or 3 new functions to the host application.
How can I program a plug-in (or a functionality) that inserts new code (new functions) in the host application without re-compiling it??
Note: I am sorry about my English. My natural language is Spanish.
Thanks anymore,
Yulien.
You didn't specify the language or the platform on which you are working, so I can only give you a generic answer.
Plugins can be implemented in several different ways. The simplest (YMMV) is to compile the plugin to a Dynamically Linked Library (DLL in Windows) or a Shared Object (.so under Linux), and then you use the appropriate function to get specific functions from the DLL and call them.
Search the internet for the function LoadLibrary() on Windows or dlopen() on Un*x/Linux systems for more information.
An alternative is to embed a scripting language interpreter in your program. Firefox, for example, is implemented in C/C++ and exposes its internals to its JavaScript interpreter (SpiderMonkey) - in this way, all Firefox plugins can be written in JavaScript.
There are different ways to accomplish this, I will give you one of the most basic.
Say you are programming with C# on Windows (Other languages and environments are similar)
Part 1. You need to be able to load an assembly (if C++ a DLL). You might want to take this from a configuration file. Do this for every piece of functionality you want the plugin applications to extend.
Part 2. You need to be able to invoke code from this plugin, so put the functionality in an interface. For example, the main application will code to an interface IMyPluginCapability and your plugin will include some class which implements this interface. You can figure out which class through reflection.
Part 3. Invoke the functions you wish your plugin to extend.
Your language, environment will surely have similar capabilities. You can lookup details for that environment.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Wether you call it Addons, Plugins or extra peices of code that is connected with the original software later, it really doesn't matter. I would love to understand how they work, there has to be a simple explanation of how to design a Plugin System. Unfortunately, I never understood it, and there remains a lot of open question in my mind. For example, how does the program find a plugin? how does it interface with it? when is it preferable for a software to have Plugin System?
Thanks for all helpful answers. It seems I asked too open question, fortunately I got keywords to look for. I liked David answer though I am not a Java guy, but his talk made sense to me :)
Plug-ins work by conforming to well-known interfaces that the main application expects to work with.
There are several ways in which a plug-in architecture actually works, but in general, these are the steps:
Plug-ins are designed to match an interface that the application expects. For example, a simple application might require that plug-ins implement a IPlugin interface.
Plug-ins are loaded by the application, usually when the app is starting up
Plug-ins are often provided access to much of the data that the application manages. For example, Firefox plug-ins can access the current web page, and Eclipse plug-ins can access the open files.
Here are two ways (out of several) in which an application can find plug-ins:
The plug-ins are known to exist in a particular folder, and the application knows to load plug-ins from that folder
Each plug-in runs as a service, and the services are designed to work together (this is how an OSGi-based application works)
When plug-ins are found, they are loaded by the application (sometimes the job of a Class Loader).
A software architect might design a plug-in architecture when they expect that either the software provider or the user community will implement new features that were not originally part of the system. Two great examples are Eclipse and Firefox; other applications include Adobe Photoshop (for artistic techniques and graphical tools) and Winamp (for visualizations).
Create an interface that all plugins of a particular type will implement
Write the code that will 'consume' the plugin against the interface only.
Have a dynamic way to load a DLL containing the plugin type that implements your interface (for instance, have a configurable folder location to test whether any DLLs in that folder contain any types that implement your interface, and dynamically load any that do. In .NET this might use Assembly.LoadFile())
If you want to have a look at some source code, Paint.NET is free and open source, and has a plugin architecture.
A program typically has to be designed to look for a plug-in, and the plug-in has to have a standard access point to accept control from the main program. Every application or website does it a little differently.
The simplest type of plug-in is accessed something like this:
if (a plug-in exists/is configured)
call predefined plug-in code
In this case, the main program is coded to only handle a specific set of plug-ins (many php-based wordpress templates are like this). A slightly more advanced plug-in
perform application specific logic
if any plug-in exists that exposes the run_after_app_specific_logic function
call plug-in code
This second case can handle ridiculously complex plug-ins ... the plug-in would just need to implement more functions called by the master program.
Eclipse in an example of a application-framework which is entirely plugin-based, meaning that all functionality is implemented as plugins. There is a thin layer at the bottom for startup/shutdown and plugin-management, but everything else is implemented as plugins on top of that. This results in a framework which can be used for just about everything. More info about Eclipse plugin architecture can be found here: http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html.
It's very language dependent.
In an interpreted language it simply involves calling a file that follows a pattern.
In C it's pretty hard to do without help. In C+windows a "DLL" can be a plug-in and are often used that way.
In an OO language with reflection, you might create an object that implements an interface and load it reflectively. After it's loaded, you can ignore the fact that it was a plug-in because it's treated as any other object in your code.
.net has a plugin architecture (is it COM?) Well anyway COM can be used as (is?) a plugin system.
Your question is probably too open-ended because of all the possibilities. There is no single answer.
I've never written a plugin system. But this is how I imagine it in my head:
Your program has a subdirectory for plugins (e.g. "C:\Program Files\My Program Name\plugins").
You create plugins as DLL files and place them in the plugins folder.
These DLLs would export functions with predefined names.
When you run your program, it looks through all the DLLs in your plugins folder. In each one it would look for an exported function with a certain name (e.g. "Load") and call that function. The plugin could then do any setup that it needed to do.
The program would then call an exported function on the plugin with a name like "GetPluginName". The plugin would return it's name and the program could then use that name when it displays a list of plugins to the user.
When it comes time to invoke the plugin, the program would call another exported function (maybe "Activate") and probably pass the plugin a pointer to the data that the plugin is going to work on. The program would then do its work on the data.
The plugin might also export another function that the program would call to show a setup dialog where you could change the plugin options.
A plugin system can be implemented in many ways, but the common way for a lot of C/C++ applications is a DLL-based plugin SDK.
The DLL will expose various automated function calls which may allow the plugin to "set itself up" in the running application such as adding menu items, new functionality or extra options for systems (like 3D rendering implementations).
More ofthen there's no need for any special discovery - the plugin mechanizm is generally dumb: Here's a code signature I understand, and here's a call(s) I can make. I have no clue how the thing I'm calling will do the job, but I expect result to be in certain format. And that is pretty much a contract. Now - the plugin will implement the contract and make itself available. In Java, for example "make available" simply means that implementing classes are loaded into memory. JDBC driver for a particular database would be a good example.