There are several versions of my applications for devices with different resolutions (9800, 9650, 9330). How can I create for him a single file. Alx? Are there other ways to merge versions of the application?
There is a good article Create a single .alx file to install multiple versions of an application
In this article there is a statement that you may use additional attributes defined in Device.xml file, which is located at C:\Program Files\Common Files\Research In Motion\AppLoader.
For your case there are two attributes model and series
Use these attributes to specify the particular device model for the application to be installed.
Related
Title explains most of it. When I create a new application project in Xilinx SDK 2019.1 and get to the templates window, the only two available options are 'Empty Application' and 'Opencv Example Application'.
When I look in the /tools/Xilinx/SDK/2019.1/data/embeddedsw directory (which is the default SDK installation repository listed ) I can find many more templates under lib/sw_apps. Directories such as hello_world, and in particular zynq_fsbl which I am looking to use, are in there.
I would like to know how I can actually use these templates and why they are not showing up when creating a new application project.
Apparently the Target Software language of the application project must be C to access these templates. I was trying to use C++.
Lazarus generates 3 file types for projects - *.lpr, *.lpi and *.lps. The first 2 files are necessary.
Should I keep *.lps files in version control system or should I include *.lps files in global ignore list?
IMO, no if you are not sharing the projects. Due to the FAQ, the lps files are "Lazarus Program Session - Personal data like cursor positions, source editor files, personal build modes. stored in XML".
This old, but as I am starting with use hg, I had the same question.
It seems best to NOT store .lps file in version control systems.
References:
http://wiki.freepascal.org/File_extensions
https://github.com/github/gitignore/blob/master/Global/Lazarus.gitignore
(Also wiki.freepascal.org/file_types and forum.lazarus.freepascal.org/index.php?topic=9298.0)
I have an app which is base in sqlite DBs and I need to create different versions of it. Each version is using different dbs, the name of them and the url to update them, and some other parameters but the code is develop to be the same in any version.
My question is how to do that keeping it simply. On android I have done several projects as library and I create a new project for each version. the new project is only a class extending from application in which I set the parameters for the name of the dbs and other strings which are defining the url etc. However in IOS I am not sure how to do that and having only one source to update for all versions.
I was reading a bit about targets but I am not sure if this is the best way, even I am not sure how to do it.
What do you recommend me? using targets? how to setup them to change the properties in the original project like the name of the database? Or do you have a better way to do that?
Every thing in the app to change the HMI or the content is in the DBs this is why I use different DBs for each version. Even I use the same DBs for the android versions.
Thanks for your help.
PS: just to clarify a bit more, the two versions has the same functions, it is just the content what is changed, and this content is in the DBs. I am not trying to have a pro and a lite version.
I think the different targets option is perfectly valid in this case, since you can decide which files go into which application. I have a similar app that shares most of the code but there are some specific resources that are specific for each application.
Just be sure that when you add new files to the project the correct target is selected, or if it's a shared resource, then all the targets are selected. You can do so in the utilities panel in XCode.
I have a Windows Installer XML (WiX 3.5) project and five localization files for my installer. Therefore WiX creates five .msi files, for every language one. How can i put all in one .msi and let the user select the language when executing the installer?
I heard something about a bootstrapper, but then i would have a Setup.exe and i need a msi file. Is it not possible to adabt the localization strings after compiling with WiX?
This can be done using transforms. Please take a look at this article:
http://www.installsite.org/pages/en/msi/articles/embeddedlang/
There are 2 parts to making this happen,
localisation of the Installer UI, and/or
choice of installed files.
The method I chose will automatically select the local (or near local) language, and can also be forced to a specific transform using command line options. This doesn't prompt the user to choose which language to install in - so maybe it doesn't actually meet your needs.
The second 'installed files' doesn't seem to be documented as well and I was recently asking about it in Why would MST not include files with different content.
As a response provided there is now an ANT build script using Windows7 SDK & antdotnet
This question is similar to this one, but not a duplicate because I'm asking about issues not discussed in that question.
I have a client-server project in Delphi 7 with the following directory structure:
\MyApp
\MyClientApp
\MyServerApp
\lib
There are 2 actual Delphi projects (.dpr), one each in the MyClientApp and MyServerApp folders.
The lib folder has .pas units that have common code to the client and server apps. What I'm wondering is if I should include those .pas files in the client and server projects? Or should I create a package in the lib folder which includes those units? Or should I just leave the .pas files sitting in the lib folder and not add them to any app/package?
What are the pros/cons of each approach? Which way is "best"? Is there any issue with having those units from the lib folder be included in more than one project?
Right now the units in the lib folder are not a part of any app/package. One disadvantage of this is that when I have my client app open in Delphi, for example, and I want to search in all files in the project for something, it doesn't also search in the units in the lib folder. I get around this by opening those units and doing a find in all open files, or using grep search (but I'd prefer a better solution).
I would also greatly prefer a solution where I will not have to go and open some separate package and recompile it when I make changes to those files in the lib folder (is this where I should use a project group?).
Sharing units between applications always carries the risk of incompatible changes done in one application that breaks the other. On the other hand, making copies of these units is even worse, so your approcach of moving them to their own subdirectory at least adds a psychological barrier to changing them without considering other programs.
As for adding them to the project files: I usually add some units which I frequently access (either for expanding or for reference) from the IDE to the project, and leave others out for the compiler to pick using the search path. I do that on per project basis, that means, some units may be part of several projects, why not?
Putting them into a package only makes sense, if you actually want to create a package based application, otherwise, why bother?
For more info on how I organize my projects and libraries, see http://www.dummzeuch.de/delphi/subversion/english.html
I dislike having files shared by projects. All too often, you'll be tempted to edit one of the shared files, and you'll either break something in the other project, or you'll forget that you have to rebuild the other project at all.
When the shared files are instead separated into their own library (package), then there's a little extra barrier to editing them. I consider that a good thing. It will be a light reminder that you're switching from project-specific code to shared code. You can use project groups to let you keep every together in a single IDE instance. arrange the library projects ahead of the executable projects. The "build all" command will build everything in order, starting with the first project.
Keep your DCU files separate from your PAS files. You can do this easily by setting the "DCU output directory" project option to send your package's units to some other location. Then put that destination directory on your other projects' "search path." They'll find the DCU, but they won't find the PAS file, and so no other project will accidentally recompile a unit that isn't really a member.
Having a separate package also discourages use of project-specific conditional defines. Those cause all sorts of trouble when you're sharing units between projects. Find a way to instead keep all project-specific options within the respective projects. A shared library shouldn't require project-specific modifications. If a library needs to act differently based on who's using it, then employ techniques like callback functions that the library user can set to modify the library's behavior.
I would need to have a very good reason to add shared code to a package. If you just have a few shared files stick them all in a directory called Shared. This should make it obvious the files are shared between projects.
Also use a good build tool to do automated builds so you will find out soon enough if you break something.
.bpl files are fine for components, but bring in serious added complexity for things like this, unless you have a huge amount of shared files.
I usually create a package with all shared unit, and just use the units.
If you do not explicitly mark "Build with run time packages" the package content (all used dcu's) will be linked to your project as any other unit.
I would only use runtime packages if you actually had two binaries that were supposed to run on the same physical machine and that shared some code. Keep in mind that runtime packages are mostly an all-or-nothing approach. Once you decide to use them you will also no longer be able to link the RTL and VCL units straight into your projects and will instead have to deploy those separately as well.
However, packages might still be a good solution to your problem when combined with project groups which is exactly what I'm doing. I hate having shared units included in multiple projects. Including the shared units in a package (but not compiling your actual projects with runtime packages) allows you to add that package to your project group so you (and the IDE!) will always have them easily accessible yet nicely separated from the project-specific code. Strictly speaking you don't even ever have to compile those packages. They can merely serve as an organisational unit in the project manager.
Note that for the Find in Files, you can also specify "in all files in project group"