I want to use x-superobject, but I can't figure out how to add it and use it on delphi xe6. I found one answer on how to install .pas files on delphi, but it is for delphi2010 and thing are a little bit different I think (I've tried that one but it didn't worked.)
So, to install xsuperobject I downloaded this two files and saved them. I don't know how to proceed, and I feel a bit stupid but I don't understand what is here on the wiki.
Thank you!
X-SuperObject is a runtime library, not a visual component library. The installation is quite easy.
Way 1: Simply put the two files to your project source folder and then you are able to use them without any problems.
Way 2: If you hate to include the files to any of your projects, you can open the Option dialog and goto Environment Options > Delphi Options > Library. You add the path of X-SuperObject to the Browsing Path.
Now you are able to include XSuperObject as any other Delphi native units (i.e. Winapi.Windows, System.SysUtils).
Related
I have found the component TColorbutton and am trying to install it in Delphi 10.4.2. I know that is currently embedded in FMX, but I want it available in VCL. However, the installation fails:
Failed to save project "c:\program files (x86)\embarcadero\studio\21.0\lib\win32\release \dclusr.dproj". The following error occurred while saving: Cannot create file "c:\program files (x86)\embarcadero\studio\21.0\lib\win32\release\dclusr.$$$"
What can I do to get it installed? Or, is there a way to use the FMX version within VCL?
The installation fails because you are trying to install the component while its unit is under the C:\Program Files (x86) folder. Since this folder is one of the protected system folders, Windows prevents Delphi from creating necessary files during compilation.
You should move the component File to a non-protected folder, like C:\Users\<YourUsername>\Documents\Embarcadero before you try to install it. This way, Delphi won't be blocked by Windows while compiling the needed component package.
It seems you're trying to "extract" a component from the FMX lib and "move it over" to the VCL lib. DO NOT DO THAT!!! If you THINK you got it to work, you probably hosed-up your installation.
You didn't say what library you installed this into, but you should always install your own components into your own component library. I use one that I call "AddOns". Some people use their name. If you try to install it into one of the system libs, you're going to find it impossible to install Delphi updates as well as any libraries that depend on those components. NEVER UPDATE DELPHI COMPONENT LIBRARIES!!! (Yes, you CAN, but just DON'T!)
VCL and FMX use totally different approaches to writing to the screen (among other things), which is why they are separate libraries. FMX has a layer between the component and the platform's "screen" (OpenGL I believe), while VCL calls the Windows API directly.
If there's stuff in FMX that you'd like to see in VCL, then look for a VCL-specific component that does what you want. Or build your own that derives from an existing one.
Search Google for TColorButton and you'll find several references to things you can use. There are some on Torry's.
There's an article on it in the newer about.com site (ThoughtCo.com) but I couldn't find a link there to the source code.
Google is your friend. Try this:
https://www.swissdelphicenter.ch/en/showcode.php?id=1100
I've created some components in Delphi and I would like to give them to somebody else for use, but without source code.
I use the latest version of Delphi (10.2 Tokyo).
What are the steps I need to follow? Thank you!
If you want to share components in Delphi without source code, you must ensure that the other user has the exact same version of Delphi as you have[1]. This won't work with a different version. Note that it does not have to be the same SKU, i.e. you can have Professional or Community and the other can have, say, Enterprise. Only the version (e.g. Berlin 10.1, Tokyo 10.2, etc.) is important.
Then you can either
put them in a package and distribute the bpl and dcp files.
distribute the dcu files.
or both (preferrable)
Note that the user will have to install these. There are instructions in the help files on how to do that (no link, sorry, as the DocWiki seems to be down right now). Note that the package must be in one of the paths in the Windows DLL search order.
You could of course also write an installer, using one of the installer creating applications like InnoSetup (no association), but that is a topic of its own.
[1] That is the reason that many Delphi developers prefer components or classes with source and would not accept or buy one of these without source. Having the source also allows you to fix little bugs.
I am trying to install a Delphi package from the VST SDk, my problem is that it says a .dcu is missing.
The .dcu is not missing, and before installing the package, it doesn't exist, but is created by the
IDE during the installation, so it's not precompiled from a former version of Delphi. The .pas file doesn't appear to be incomplete. All the other files appear to be installing just fine, this however is giving me a great load of trouble. I hope someone might help me :)
Im using Delphi 2010 btw.
Thanks in advance :D
Image showing my files and errors
Here's the SDK - im using 1.3
The problem is that the compiler cannot find the source files, or the dcu files.
There are several ways to solve this.
You can add the paths that contain the .pas files to your library, via /tools/options/EnvironmentOptions/DelphiOptions/Library/LibraryPath
You can add the paths to the search path of the project.
In the project options (ctrl+shift+f11)
You can add each file that you need to the project. shift+f11
Note that you can also point to the folder that contains the .dcu files, but that means you wouldn't be able to step through code when you're debugging.
I usually use method 1, because that settles it for all future projects that you use in this IDE. It's convenient if you create many projects that use the same library.
Some other people like to specify this per project, so that they have full control over the dependencies of the project.
I am a .Net programmer and I'm currently debugging a Delphi application and as I go along
I encountered the following error:
Could you explain to me what is this error, and how I can resolve it?
I am new to using Delphi.
Error Explanation
The error that is been presented to you is telling you that a component on that form is not registered in the IDE, in this case TsStatusBar which is from the AlphaControls library: http://www.alphaskins.com/
The form would have been saved at some point with TsStatusBar placed on the form. When any component is added onto a form they leave references to the component in both the forms source file (*.pas) and the inside the forms dfm. This is why you are getting this error, because the component cannot be found, yet the references linking to it still remain.
Option 1 - Install the AlphaControls packge
The best option would be to install the components that are missing, this will solve your error problem as shown in your question.
Option 2 - Convert Project
AlphaControls provides a tool to convert a project from standard VCL to AlphaControls and vice versa, this may be an easier option then installing the AlphaControls package or manually editing source files, the convert tool is free. Just remember to make a backup before converting should anything go wrong.
Option 3 - Manually Editing the Source Files
You could manually remove these references yourself. Do note though, if you remove the references then Delphi will no longer know that the TsStatusBar was ever there, and without a doubt there will be code somewhere that would have interacted with this component which will create compiler errors.
As an alternative to removing the references, you could rename them from TsStatusBar to TStatusBar, which is a standard statusbar from the VCL. At worst there may be some small syntax errors that may need correcting. If you do decide to edit the forms source and dfm files then I would suggest you do it before loading the form into the IDE.
Option 4 - GExperts
You can also install an IDE Expert such as GExperts which can automate the process of renaming/converting component references.
I would however advise against removing or renaming the references in this circumstance as it seems the project is reliant on the AlphaControls package.
Summary
I can see there are more components from the AlphaControls package been used, so fixing the TsStatusBar error manually will only fix part of the problem.
If the project must remain in its current state then Installing the AlphaControls package is the way to go, if you are able to edit it then I would also suggest the project convert option, this way you won't even need the AlphaControls package.
If you do chose to install the package, it is important to realise that once you install the package Delphi knows where the source files are to be able to compile. After installing the packages, goto Menu > Tools > Options from the IDE, then you need to go to Library and add the folder for the AlphaControls source to the library path. The source folder will be the one containing the most .pas files, but you could add all folders if you are unsure. If you don't add to the Library path then Delphi will not be able compile when using the new components.
Your IDE does not have the package which contains TsStatusBar installed. Find that package, build it, and install it.
Design time components need their code to be integrated into the IDE. This is done using what are called packages. The package project has extension .dpk. You should find this package project in your revision control system. Load the .dpk file in Delphi, click Build from the package manager, and finally, when built, click Install. Now that the package with your component is known to the IDE, your form will load. Whoever maintains this code in your organisation will be able to help with all the details.
I am trying to start making my own libraries avaialble as packages prior to compiling my Apps with these packages hence modularising my code. For years I've 'sort of' understood packages, breathing a sigh of relief when I load a component package and click on 'Install' and it does. I understand that the process of installing a component (or components) is via the creation of a BPL which is then registered with the IDE.
Where I begin to get lost is how to make files available so that I can compile with EITHER a package OR pre-compiled dcu's (like the third party vendors do) and without pointing my project at the source code all the time. I can create a package with the following settings:
where I've specified that all my output will go into 'c:\scratch\wow'. After a build I find TEST.BPL, TEST.DCP and lots of DUC's. Now, when I point another project at this folder to use the DCU's, I get a missing DFM error (one of the units is a form). Should I be manually copying needed DFM's into this output folder? The DPK knows about this form, so why do I not get the DFM copied for me? I presume that using TEST.BPL, that file contains everything, but I wish to work in the two modes. Of course I can get around this by including the source folder in my project search path to find the DFM but third party libraries seem to already have the DFM's in their output folder. Did they install them there using the installer?
Thanks
instead
As others say you could use post-build events to copy your DFM files into place. Other people use a one-time external batch file that copies the DFMs to the DCU folder.
Personally I see very little benefit to making packages for things which are not developed also as reusable components. I also see very little benefit in partitioning an existing application into packages, when you don't reasonably need to use the same subsection or package more than once, or at designtime.
Things I would put into packages:
Delphi visual and non-visual components.
Things which absolutely must be plugged in at runtime, or left out. For example, supposing I sell MetaWare Light and MetaWare Pro, and instead of using compiler IFDEFs to build a differnt binary, I preferred for some reason to simply not ship the ADVANCEDFEATURE.BPL with my systems.
Things to beware of with packages:
I have run into a lot of compiler bugs when combining packages with generics. I have also run into IDE crashes and lockups, in Delphi 2009, 2010, XE and XE2. (I believe XE3 is better)
You should learn a bit about BorlandMM.dll and shared memory management in the BPL world before you move to it. There are some subtleties.
Packages limits the ability of the linker to decide what to remove. In fact, it pretty much destroys it. Packages contain everything that is linked into them, and nothing publically accessible can be removed.
Once you've created a binary package and shipped it to even one customer, you have a pretty difficult to modify contract (this BPL contains a particular signature or application binary interface) you have to be careful in the future to never change them, or mix and match them. Beware of DLL hell, even among your own customers, and be prepared to use versioning on your packages. Just as delphi packages have a version suffix, I recommend you use version suffixes in your own packages right off the bat, and bump them whenever binary compatibility has changed.
Delphi handles build dependencies between packages about as well as could be hoped, which is less well than a single monolithic application. In applications that I have that make heavy use of packages, I find project groups that contain a bunch of packages that depend on each other are very difficult to manage and build quickly. In fact, I have experienced that both compiles and builds are slower and more frustrating than they would be in a singular 750Kline megaproject.
I really wonder if you're not that into the package area of Delphi (you breath a sigh of relief whenever a delphi component actually builds and installs without issue?) if you really want to move into the Packages World totally. By all means, you should experiment. But I wouldn't bet the farm on it yet. Learn some more first.
Yes, you should copy the .dfm to the directory with the compiled units (.dcus), if that is the only directory you want in your search path. The BPL will of course contain the .dfms, and you need a .dcp to be able to link a BPL with your app.
Third party tools must have put the .dfms together with the .dcus in the directory using their installer, indeed.
Instead of copying *.DFM manually you can use Post-Build Event (Project/Options/Build Event), ex:
copy “$(PROJECTDIR)\Unit1.DFM” “c:\Scratch\wow\Unit1.DFM”
I found a way to do this without moving .dfm files to the directory of .dcu files, so you can have a directory for .dcu files only one for .dcp files only and another for .bpl files only.
All you need to do is to create another directory on your good structure, as I do. The directory is called RES and in it should be placed all the resource files (.res files, not .dcr files) that are used by applications compiled using your packages (components). In the Delphi Library Path, you must include in addition to the DCU directory (you should already have) a directory named RES.
On your component (design time) do everything you want with the form (design it, put other components, etc). In the source code of the unit you replace {$R *.dfm} with {$R UnitName.dfm}. In doing so, save all and close the DPK. Now move the .dfm file (do not copy, move!) to the RES folder (the .dfm file is a resource file to the Delphi. The {$R} directive is proof!) and after that open the DPK again to understand what has changed.
First realize that you may not open the form (F12) from his unit, though no error was issued by Delphi about "DFM missing".
Now, do a Build on your package and then install it. Realized again? No errors displayed! This happened because you have indicated the location of .dfm file in the Delphi library search path (RES directory).
Done! You can use your component and dfm will be found when your component is included in an application.
Many of you can now say that this way I will not longer be able to visually edit a form in the component design time. Yes this is true, but if you think about it, why would I want to change so often a form into a component that, in practice, should only be used and slightly edited? Draw your own conclusions ;)