We have our own fonts for our application. We are using Windows Vista operating system to develop the reports using iReport. We are using iReports 3.7.1.
I kept all my fonts in a folder in C:\ drive. I gave fonts path in iReport.
Still I am getting 'Could not load the font' error while generating the report.
The same worked fine on Windows 2000 and with iReport 2.x versions.
This is, er, not exactly a timely reply. But you should use font extensions. They were added to handle this type of problem.
Putting your font files into the classpath also works in many cases (as you indicated). But it fails for some unanticipated reasons as well (as you indicated!). Font Extensions will avoid these problems.
Related
I have a Windows desktop C++ application that currently uses ::PathCanonicalizeW. As you can see from the documentation, it was introduced in Windows 2000 and is located in shlwapi.dll. In order to support long paths on Win 10+, I need to start using ::PathAllocCanonicalize (or one of it's friends - ::PathCchCanonicalize or ::PathCchCanonicalizeEx).
This function was added in Windows 8, but I still need to support the older OS's. In order to support all OS's, I need to dynamically load ::PathAllocCanonicalize by calling ::LoadLibrary at runtime. The problem is that the documentation doesn't provide the DLL that includes this function.
After doing some searching, I found this documentation that includes all 3 of the new PathCanonicalize functions and it claims that they are in api-ms-win-core-path-l1-1-0.dll. After more searching, it appears that this is not a traditional DLL because there is no file anywhere in the OS with that name. This application has always loaded system libraries using the full path to the file in the system directory (typically C:\Windows\system32) to make sure that it's not loading malicious DLLs, but for this it will be impossible without a physical file to point to.
I have been able to test that calling ::LoadLibrary("api-ms-win-core-path-l1-1-0.dll") does work, but the fact that that documentation mentions UWP worries me. Is there any documentation for the supported way to dynamically load these kinds of functions at runtime in a desktop app? Is there a more secure way to load this DLL?
P.S. This app cannot be deployed with that DLL, and even if it were possible there's no point since any OS that doesn't have that function wouldn't have full support for long paths anyway. Using the documented pathcch.lib would require upgrading the target Windows version. Dropping support for the older OS's is also completely out of the question. The function must be manually dynamically loaded at runtime.
As pointed out by Hans, api-ms-win-core-path-l1-1-0 is known as an API set along with many others starting with api-ms-win-core. Based on the documentation there, it appears that the documentation for PathAllocCanonicalize is incomplete. It should list the API set on that page along with the DLL for desktop apps. Looking at the source on GitHub, it looks like there is a bug with that page and the other pathcch functions where that information is in the header but not rendered onto the page. That header lists api-ms-win-core-path-l1-1-0.dll and KernelBase.dll.
If for some reason I wanted to continue to load the API set instead of KernelBase.dll, ::LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) worked which would be just as secure as specifying the full path to a DLL in the system32 folder. Note that LOAD_LIBRARY_SEARCH_SYSTEM32 was not supported without KB2533623 on RTM versions of Vista, Windows 7, Server 2008, and Server 2008 R2 so that might not actually be secure on those OS's.
I built a Lazarus program and it's now in exe form.
I am able to run it on two of my computers running XP and Vista.
However, there are other computers as well running XP, Vista and Win7 but I cannot get it to run at all on them.
There are no errors, nothing... Has anyone else had this issue?
The program is connecting to a postgres DB on my LAN server.
Any idea on fixing this is really valued.
NEW INFO:
Maybe I'm wrong but here's a thought... On the development machine, I initially got an error like **libpq.dll* not found when I first tried to connect to postgres. Then after setting the path, it was fine. I'm thinking now if it cannot find that library and that's why it's not able to run.
If this is the case, should my line Application.OnException:=#CatchErr; catch the error? If not how else should I check if this dll or anything else is missing?
First, a sincere and big THANK YOU to Marco and MArtyn for the great tips and guidelines hat got me thinking of this strange issue.
Here's what happened...
I installed a fresh copy of Windows 7 and XP. As usual it did not work.
Then I suspected the old problem of libpq and then I copied libpq.dll from my working OS and put it in the application folder. By the way this machine has no Lazarus or Postgres. The moment I did this, I got my first error message saying that msvcr100.dll was missing.
And then I copied that as well. So the cycle of copy pasting went on for each and every error until I had finally brought these files to my 'non-working'.
libpq.dll - 9.2.1.12263 - PosgreSQL Access Library
msvcr100.dll - 10.0.40219.1 - Microsoft C Runtime Library
ssleay32.dll - 1.0.1.2 - OpenSSL Shared Library
libeay32.dll - 1.0.1.2 OpenSSL Shared Library
libintl.dll - 0.18.1.0 - LGPLed libintl for Windows NT/2000/XP/Vista/7
Once these files came in, the problem was gone!
Now the program works great :)
Thanks for all your inputs!
I now have to see what the above files have to say about their licenses as I have to distribute the app to other users. But I'm glad at least we figured out the problem.
No, base Lazarus programs don't require special permissions. Of course it could be that a specific functionality in the program requires special permissions (like access to ports below 1024, access to certain paths etc).
Also be aware that EXE's downloaded from what the system considers insecure sources (internet, certain kinds of shares) might be blocked by default. If that is the case, if you take the properties of the .EXE in windows explorer, there will be an "unblock" button.
Anything network related of course requires proper configuration of the firewall. The popups that query you might not always come, in case of doubt configure the firewall manually.
My environment : Win7, VS2010 Pro, Windows Phone Emulator 10.1.40219.390, HTC T8788, Windows Phone Power Tool v1.6.
I need to Get multiple files (they are <3kb json files) to my dev box from a folder on my emulator/device. I had been happily doing this with Isolated Explorer command tool and/or Windows Phone Power Tool till the number of files was very limited. As soon as the number of files increased in the folder both the tools mentioned above failed to open the folder from device. The application on device and emulator is handling large number of files as expected (tested with 4000+ files). Following are my findings regarding the issue with WPPT (and IS explorer): if a folder contains more than 1024 files, WPPT does not load the folder. The physical size of individual file in the folder does not matter. The issue can be reproduced with same effect on emulator and device. On further investigation I found that WPPT breaks at a call to Microsoft.SmartDevice.Connectivity.RemoteIsolatedStorageFile.GetDirectoryListing() which just says - "Unspecified error" with no details. It seems the said API method is now obsolete and i could not find any substantial information on MSDN about it or the issue
Did somebody else also encounter this problem? Is there some way I can pull large number of files (4000+) to my dev box from IS folder on device/emulator (please note, i can only work with the environment mentioned above, so Win8 or WP8 emulator are out of question)?
Regards.
I'm working on an application developed for Windows XP SP3, using VB6. I'm currently in the process of getting it to work on Windows 7, but am encountering a problem with one of our custom OCX files.
When attempting to load a form that contains an instance of the control contained in the problem OCX, the following error is produced:
Failed to load control 'x' from y.ocx. Your version of y.ocx may be outdated. Make sure you are using the version of the control that was provided with your application.
I've checked the version numbers and they're all correct and referencing the proper version. The OCX registers fine, and all the expected registry entries are present.
Inspection with DependencyWalker shows no missing dependencies.
The software works fine under XP, and this is (seemingly) the only issue when running on Windows 7.
Interestingly, if I run through the VB6 IDE using a VB6 group (with the offending OCX part of the group, and the application the startup project), I don't have the issue. Running the application on it's own through the IDE still presents the error.
Any ideas on what could be missing which would cause the application to throw this error?
Error occurs on both Windows 7 Professional and Home Professional, both 32 bit.
This is almost certainly an interface compatibility problem. COM interfaces are versioned entirely separately from your Major/Minor/Revision numbers, which are little more than comments except as used by Installer.
Somewhere along the line you broke binary compatibility, and you are trying to deploy a library with a newer interface than your application was compiled against.
These version numbers are found in keys such as:
HKEY_CLASSES_ROOT\CLSID\{class Id GUID}\VERSION
Your program needs to have its old reference to the OCX removed, a new one set, and then it must be recompiled. This also means deleting any instances of the control and adding them back one by one.
I doubt this is a Windows 7 issue.
I would suspect this is a UAC problem. Try turning UAC off to see if that solves the immediate issue. If it does then you have to regsiter everything using 'run as administrator' and/or create a manifest for you application.
Sounds like on of the controls included in your OCX is having issues loading, not a general registration error. Look at the constructors for x control, and see if they are doing anything that disagrees with UAC or such. One way you can debug this is put some kind of a break before the control is initialized, and debug the application from Visual Studio (remember to create the PDB's in VB6), and then carry on from the break to see why the control isn't initializing.
Using VB6
i created a software in vb6 with xp operating system, In my system, software is working perfectly. When i run my software in other system(xp operating system), it showing error as cannot find project or library, showing error in Date, Left...,
Now i moved to vista operating system, i try to run my software, It showing the same error.
How to solve this issue.
My software is running in my system, when i try to run my software other system it showing error and also i try to run my software in vista also it showing a same error.
What happen in my code. There is any system32 file problem?
How to solve this issue.
Sounds like you need to create an installation for your VB6 project, to install the VB6 runtime and any non-standard components used. The runtime should be present by default on Vista, so it's probably non-standard components that are missing.
Consult the answers to your own previous question in August, when you asked how to make an installation for a VB6 program. (Even that August question was already a duplicate.)
You need to also copy the controls, and referenced files to the machine running your code. Some controls and referenced files will already be on the machine, but without experience you generally will not know which files are already installed. You can look at the checked files in the Project|References and Projects|Components dialogs to see what is included in your project. You will need to scroll through the components dialog to find all referenced files, but in the references dialog all the references are organized at the top. Also, to confirm what file(s) a machine is missing you can look at the Events log. An error with the missing file will be logged. A drawback of this approach is that you will only get one missing file at a time as the Application quits on the first missing reference encountered.
Also MarkJ and Konamiman are both correct in that the VB6 runtimes are required, although it is common for other VB6 programs to have already installed it. If you are not building in-house applications you do not want to take anything granted and should build a complete install for your application.
The other computers must have the VB6 runtime in order to run applications generated with VB6. Maybe is this the problem?
The VB6 runtime can be donwloaded from here: http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9a24f9-b5c5-48f4-8edd-cdf2d29a79d5&displaylang=en
Use the Package and Deployment Wizard to create a setup.exe. The Wizard will automatically include all the files you might need for distribution.