I'm running into an issue where after building an application with Powerbuilder, some users have no issue with viewing icons within the application while others can't see the icons. Also, the main icon for the application doesn't display on the Windows Task bar. I'm going to play with the icon size but if anyone else has any recommendations, that would be great!
I don't like to re-compile the executable every time there's a small graphic change or a customization that applies to only one library, and I don't like to compile graphics into the executable... it makes the exe file very large. No reason to rebuild the exe unless the library list changes. So I use .pbr files, and just rebuild the pbl with a pbr file.
My graphics.pbr file resides in the same directory as my graphics so I don't have to mess with environment variables or worry about file paths. I created an empty graphics.pbl in the AppCore directory, and a graphics.pbr in the graphics directory. The graphics.pbl is in the application's library list. When I have to add or edit graphics, I simply rebuild the graphics.pbl with the graphics.pbr.
I have multiple customers using the same application, with their own graphics (logos) so I do the same thing there. Here's what my directory structure looks like:
MyApp
MyApp.pbw
AppCore
graphics.pbl
bunch more libraries
AppGraphics
single resource file, graphics.pbr
bunch of icons and graphics
Customer1
Customer1.pbl
Customer1.pbr
a few libraries for customization and container for application object
a few custom graphics
Customer2
etc.
The key is to make sure when you add graphics or images to your application from the AppGraphics directory (or the customer directory), make sure there is no directory path.
This solution has made it easier for me to continue developing the next upgrades and versions by moving the code and renaming some directories without having to edit my code because my directory path has changed.
This is lengthy, but I hope it helps!
~~~Tracy
Within the IDE where you insert the icon file name, make sure you don't have a path (like "C:\graphics\myicon.ico") - only the name of the icon file. Then make sure the icon files are somewhere in a folder within the PATH variable on your system. When you build your application you can use a PBR file (a resource file) in the project for the application. If you list all the graphic files used in the application in this resource file they will be included in the exe (and you won't have to distribute them separately).
Matt is right on point with not using path names in your image references in the app. Also correct that it is best to compile them into the app.
However, during development I like to separate my resources and DLLs into separate directories. To do this without changing global env variables, you can include your directories in the PB "App Paths" registry section.
Depending on your PB Version...
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\pb125.exe"
There you will find a "PATH" value. Just append your dev, resource, dll, directories to that path separated by ";" and PB will find them (requires restart).
I actually create reg files in the root of each app I'm working on to quickly register my paths.
NOTE: The same thing works with your final compiled application; but instead of using the PB section, there will be section created with the name of your executable. Just do the same thing there - add paths where resources are separated from the EXE directory.
Related
There are 2 processes. One is a GUI process that is located in MacOS folder under the Mac bundle, while the other one is a tray process that is located in Resources folder under the bundle. The tray process doesn't seem to be able to find the cocoa plugin/library. Because when I manually run it, there is an error as below
This application failed to start because it could not find or load the
Qt platform plugin "cocoa" in "".
The bundle structure looks like this
-Contents
|_MacOS
| |_gui
|
|_Resources
| |_tray
| |_qt.conf
|
|_Plugins
|_platforms
|_libqcocoa.dylib
qt.conf contains
[Paths]
Plugins = PlugIns
Imports = Resources/qml
Qml2Imports = Resources/qml
Is the right thing to do that putting tray process into resources folder within a Mac bundle?
According the Bundle Programming Guide the Resources folder is intended for resources like images, sounds, etc (see Table 2-5):
Contains all of the application’s resource files. This contents of this directory are further organized to distinguish between localized and nonlocalized resources. For more information about the structure of this directory, see The Resources Directory.
and:
The Resources directory is where you put all of your images, sounds, nib files, string resources, icon files, data files, and configuration files among others
The MacOS folder however may also contain helper executables:
Contains the application’s standalone executable code. Typically, this directory contains only one binary file with your application’s main entry point and statically linked code. However, you may put other standalone executables (such as command-line tools) in this directory as well.
Therefore, I think the MacOS folder is the best location for your tray binary. I don't know whether that solves the problem of the missing platform plugin.
This may sound like I'm just looking for a .exe file, but I'm not all that familiar with windows. I have been using pyinstaller to turn my apps into binaries. My app relies on a lot data directories and third party binaries that I package within the same directory as the executable binary. For Mac, this makes things easy because the user only has to click on MyApp.app inside the applications directory which is like a link to MyApp.app/Contents/MacOs/MyApp. This way MyApp never has to be touched and is all bundled together with the data directories (also loaded inside of MyApp.app/Contents/MacOs/).
However, I can't really find a windows equivalent. While Pyinstaller can create a directory with my data directories and executable inside of it, if the user ever moves the .exe file inside the directory, the app will never work (because it loses its relative location to the data directories). Is there such a thing that can package this directory like on MacOS so the user just has to click on a single .exe file that links to the .exe inside the directory packaged within it? That way we can just pass around one directory. Like a Mac.app?
Win32 apps store data within the executable file as resources, which allows the single file solution, but they can't be accessed using normal file APIs, there are a separate set of functions for resource handling. (This implies that resources aren't so useful for things that absolutely have to be files, like images of helper executables.)
Win32 also has alternate data streams, which are more similar to what you're used to with .app packages, separating a local identifier from the actual filename by $DATA:. But those only work on NTFS, get lost by many file management applications, never have been very popular, and are now effectively deprecated by Microsoft (by preventing access from Windows Store apps).
I want to know how installation in windows works like what sort of files get created first as .dll , drivers & all.
To be more precise when we click on .exe file what happens internally?
Generally speaking, anything can happen after you click the exe. But most of the time, installer does some or most of these:
check if the needed frameworks and libraries are already installed (ex: .NET framework)
create a registry entry with the application settings and uninstaller path
extract the binaries and assets or download them
create the needed directories (ex: Program Files/SomeProgram) and move the extracted files to the proper folders
create a desktop shortcut
associate the file extensions with the program
do whatever else the program needs.. It really depends on what you are installing and what needs to be set up for the program to
function properly.
I have a set of applications that work together. It should be possible to start each of these applications individually by the user (i.e. one application provides a monitoring feature, another a configuration feature etc), therefore I would like them to show up in the Applications folder as different applications (possibly within a directory).
The applications are based on Qt5, so I would like to package Qt along with the applications privately to ensure that Qt is present and available. On the other hand I would like to make sure that I only include a single copy of Qt to avoid bloating the system.
I am using a package installer, due to the inclusion of a LaunchDaemon as well.
How do I place the Qt frameworks needed in order to avoid having multiple copies?
Here's the naive way:
/Applications/
MyCompany/
Foo.app/
Contents/
Info.plist (must use its own plist to specify some properties)
MacOS/
foo
Frameworks/
Qt-Goes-Here??
Bar.app/
Contents/
Info.plist
MacOS/
bar
Frameworks/
Qt-Goes-Here?? - Or can this be a link to the other location?
Since I am not a Mac-guru, any input (including informing me that I am trying something stupid) is very welcome!
There are two possibilities here, the first is
/Library
and the second
/Library/Application Support
If you look there, you'll find folders with contents for various applications. You should be able to create a folder there and add the Qt Framework, then update your applications to point to that using install_name_tool
The docs state the following for /Library: -
The Library directory is the top-level directory for storing private
app-related data and preferences. There are several Library
directories scattered throughout the system but you should always use
the one located inside the current home directory. Do not store files
directly at the top-level of the Library directory. Instead, store
them in one of the specific subdirectories described in this table. In
OS X v10.7 and later, the Finder hides the Library directory in the
user’s home folder by default. Therefore, you should never store files
in this directory that you want the user to access. To get the path to
this directory use the NSLibraryDirectory search path key with the
NSUserDomainMask domain.
For /Library/Application Support: -
The Application Support directory is where your app stores any type of
file that supports the app but is not required for the app to run,
such as document templates or configuration files. The files should be
app-specific but should never store user data. This directory is
located inside the Library directory. Never store files at the top
level of this directory: Always put them in a subdirectory named for
your app or company. If the resources apply to all users on the
system, such as document templates, place them in /Library/Application
Support. To get the path to this directory use the
NSApplicationSupportDirectory search path key with the
NSLocalDomainMask domain. If the resources are user-specific, such as
workspace configuration files, place them in the current user’s
~/Library/Application Support directory. To get the path to this
directory use the NSApplicationSupportDirectory search path key with
the NSUserDomainMask domain.
The full documentation can be found here.
I am using Xcode as part of my build for OS X, but since it is not the only IDE used, files may be added from the file system directly.
As far as I can tell, there are two ways of adding folders:
Folder reference picks up all the changes on the file system but does not register any of the files as sources.
Recursive copy allows for the files to be built but I need to constantly maintain the file structure
I am wondering if there was a way to setup Xcode to build all of the files that are a part of the folder reference or failing that, if there is a quick script to automagically fix file system discrepancies.
I came up with proof-of-concept solution that works, but will require some work to use in production. Basically, I set up a new "External Target", which compiles all source files in a given directory into a static library. Then the static library is linked into the Main Application.
In detail:
Create a directory (lets call it 'Code') inside your project directory and put some source code in it.
Create a Makefile in the Code directory to compile the source into a static library. Mine looks like this.*****
Create an External Target (lets call it 'ExternalCode') and point it to the Code directory where your source and Makefile reside.
Build the ExternalCode and create a reference to the compiled static library (ExternalCode.a) in the Products area of your project. Get Info on the reference and change the Path Type to "Relative to Built Product".
Make sure ExternalCode.a is in the "Link With Binary Libraries" section of your main target.
Add the ExternalCode target as a dependency of your main target
Add the Code directory to your "User Header Search Paths" of your main target.
Now when you drop some source files into 'Code', Xcode should recompile everything. I created a demo project as a proof of concept. To see it work in, copy B.h/m from the 'tmp' directory into the 'Codes' directory.
*Caveats: The Makefile I provided is oversimplified. If you want to use it in a real project, you'll need to spend some time getting all the build flags correct. You'll have to decide whether it's worth it to manually manage the build process instead of letting Xcode handle most of the details for you. And watch out for paths with whitespace in them; Make does not handle them very well.
Xcode's AppleScript dictionary has the nouns and verbs required to do these tasks. Assuming your other IDE's build scripts know what files are added/deleted, you could write very simple AppleScripts to act as the glue. For example a script could take a parameter specifying a file to add to the current open project in Xcode. Another script could take a parameter to remove a file from the current project. Then your other IDE could just call these scripts like any other command line tool in your build script.
I'm not aware of any built-in functionality to accomplish this. If you need it to be automatic, your best option may be to write a Folder Action AppleScript and attach it to your project folder.
In all likelihood it would be a rather difficult (and probably fairly brittle) solution, though.
It's not pretty, and I think it only solves half your problem but... If you recursively copy, then quit xcode. Then you delete the folders, and replace them with simlinks to the original folders, you at least have files that are seen as code, and they are in the same files as the other IDE is looking at... You still will need to manually add and remove files.
I sort of doubt that there's a better way to do this without some form of scripting (like folder actions) because xcode allows you to have multiple targets in one project, so it's not going to know that you want to automatically include all of the files in any particular target. So, you're going to have to manually add each file to the current target each time anyway...
One way to import another file from add/existing file:
and set your customization for new file that added .
see this