I have a project in Visual Studio 2017 Enterprise with PHP Tools installed. Every project file has ISO-8859-2 encoding (codepage 28592 in VS terminology), and everything works well until I try to open any file. VS wrongfully guesses the encoding as Windows-1250 with no visible way to override this project-wide. This leads to national diacritics being loaded wrongfully and requires reopening every file with encoding manually specified.
Any ideas (other than manually specifying encoding every file opening) how to force the encoding to ISO-8859-2 per every opened file in this project - without manual intervention?
(To reduce any concerns why this particular encoding is used: the program has to comply with the national norm PN-T-42118, specifying this encoding as mandatory. This norm must be complied with at all times in the whole project - a design requirement.)
In VS 2017 it is typically controlled by an EditorConfig file with the charset property.
Related
On my development machine, I have Delphi 10.2 and Firebird 2.5. Database apps that I create in this configuration work correctly.
I copied one program along with its database to another computer running Windows 10. I installed Firebird; I also installed SQL Manager Lite for InterBase/Firebird on this computer, and this program is able to open the database and view the data contained within. But my Delphi program cannot open the database, displaying the error message 'Unable to load dbxfb.dll (error code 193). It may be missing from the system path'.
I have copied dbxfb.dll to every location that I can think of (the same directory as where the program is, the same directory as where the database is, windows\system32, C:\Program Files (x86)\Firebird, and more) but the message stays the same. On my development machine, what I believe to be the path (i.e. system properties\advanced\environment variables) contains only the directory %USERPROFILE%\AppData\Local\Microsoft\WindowsApps. On the other computer, I added C:\Program Files (x86)\Firebird but to no avail.
So where should dbxfb.dll be located, or how do I "tell" my program where to find it?
Edit: Regarding 'bitness', both computers are 64 bit. In the Project Options dialog box in Delphi, there is only the option of 32 bits. I've set the program's compatibility setting to Windows 8, but this made no difference regarding the missing dll.
Further edit: The version that is/was on the target machine is 1,412kb in size and dated 13/11/2015 1:55; this version apparently comes from C:\Program Files (x86)\Embarcadero\Studio\17.0\bin64, so this is definitely the wrong version.
In C:\Program Files (x86)\Embarcadero\Studio\17.0\bin, there is a version that is only 278kb in size, same date but hour 06:55. Copying the smaller file to the target machine and running the program gives now a different error message: i/o error during "#1" operation for file "#2". Error while trying to open file.
https://learn.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-
ERROR_BAD_EXE_FORMAT
193 (0xC1)
%1 is not a valid Win32 application.
It is indeed the bitness problem as suggested by Mark.
I'm using Microsoft Visual Studio Express 2012 for Web. It seems that every file which I open with it gets encoded into UTF-8. For most files which are going to be web-facing, that's fine. However, I have files in my projects that are specifically for build purposes (e.g., .bat files), which must be encoded in ANSI.
Are there any configuration settings in VS to either designate on a per file or a per extension basis the encoding? Or, if not specify the encoding, at least disable the auto-conversion to UTF-8?
Open the problematic file in Visual Studio and...
On the File menu, click Advanced Save Options.
In the Encoding dropdown, select Unicode (UTF-8 … or the encoding you require.
Click OK.
Also see:
how to change source file encoding in csharp project (visual studio / msbuild machine)?
An option to handle the encoding of all files of a given extension on a per open basis can be configured in the Options dialog. See MSDN page on Options, Text Editor, File Extension.
Navigate to Tools > Options > Text Editor > File Extension.
For the bat extension, I selected Source Code (Text) Editor with Encoding. The with Encoding part means that the user will be given options as to what encoding to use when opening the file. The default in this mode is Auto-detect, which preserves the ANSI encoding, if that is what the file already uses. Otherwise, one can explicitly designate it for the individual file.
Unfortunately, it doesn't seem to remember the setting last used when opening a file, and will thus prompt for an encoding setting every time a file is opened.
I had code conversion problems width VS studio 2012 as well. Namely, I had non ansi compliant characters in strings ind my .js files and unreadable was outputted to the browsers html page.
I figured out that accept script files (like .js) VS 2012 creates all files in UTF-8.
*The problem is with the suggestion bellow to change the defaults in the options dialog resulted in that the syntax highlighting and intelisense stopped working in all .js files.*
So my workaround solution know is that I convert my .js files with notepad++ to utf-8 without BOM.
In this way my "unusual" chars are appearing well in browsers and the intelisense is working fine as well.
I'm generating C# source code which is being built by both VS2010 and Mono's xbuild (2.10.2.0). This generally works very well, I've only had a single compatibility issue so far, and in that case I was using a 'feature' that is clearly specified as undefined behaviour (so mea culpa).
Now I'm running into an issue where I have special characters in a string literal in the C# source code. I'm generating the source files in UTF-8, the character I'm testing with is a German sharp s: 0xC39F. This is written to a file in latin1 by the code, where it ends up as 0xDF when the executable is built with VS (that's the one I want) and as 0xC33F when built with xbuild.
It does not seem to matter whether I run the executable with the .NET or with the Mono CLR, as far as I can see.
My current suspicion is that xbuild is not reading the source code as UTF-8, so the compiled code already has the wrong character in the string literal. Is there a way to explicitly tell it to? I couldn't find anything on xbuild /? and the xbuild documentation isn't particularly comprehensive. If I just missed the right page where this is documented, just a link is sufficient, of course.
All experiments have been performed on Win7 x64.
EDIT 1: To clarify, I've used a hex editor to confirm that the character in the source code file is really 0xC39F, the character written when compiled with VS2010 is 0xDF and the character written when compiled with xbuild is 0xC33F.
You'll need to modify the .csproj file(s) and add a <CodePage> element to the <PropertyGroup> section.
You should be able to use Visual Studio or MonoDevelop to do this for you, as well.
In MonoDevelop, if you right-click on a project and select the "Options" menu item, you can then go to the Build/General section and there will be a "Compiler Code Page" field which you can use to select "UTF-8".
FWIW, this is what MD outputs when I select UTF-8:
<CodePage>65001</CodePage>
So you can just copy/paste that into the <PropertyGroup>
I read in a blog about Version Insight (http://www.delphifeeds.com/go/s/77066) that (among others) JCL doesn't have its .dproj files under version control and i was wondering what the advantages of that would be.
Especially since me and my collegue developer often "bug" each other with checking in project files with our own favorite debug settings (he likes optimization on, I want it off). And because of the regular hick ups of Delphi 2007 that screw up the dproj file with all kinds of faulty dependencies. Does not versioning help in anyway with these things?
We are using Starteam as our VCS at the moment.
If you're using Delphi 2009 or later Option Sets are a perfect solution for this problem.
Option sets are basically collections of settings that would normally reside in the DPROJ (which you do version) but instead stored in a .OPTSET file (which you don't version).
Make your DPROJ contain the settings that are common to all developers, that nobody is allowed to change unless it's an agreed across the board change.
Next in the project manager (D2009 and above) on first the DEBUG configuration node and then the RELEASE configuration node, right click and select "New Option Set". Call this option set something like "Local Developer Debug Settings.optset" and "Local Developer Release Settings.optset".
Now commit only your DPROJ to version control as it now refers to these .OPTSET files. You must name your option sets exactly the same on each machine for this reason.
When you want to make a local change to your project configuration rather than editing the project configuration, right click on the Option Set in the project manager and select "Edit Option Set".
The IDE will apply the changed settings from the option sets without modifying the original DPROJ. Settings are applied hierarchicly with option sets being the last to be applied.
I store, in my .dproj files, settings that are used by msbuild for my build process. For example, conditional defines, compiler settings, etc. If you do the same then you need to version them.
If you are using a version of Delphi where the IDE breaks the .dproj file on a regular basis, then surely revision control will help you fight back.
I can't see any advantage in not versioning them.
If you choose not to version your DPROJ, when creating your release builds I recommend you use a separate build script of some sort that you do version e.g.
a batch file that calls the command line compiler and specifies the compiler options and paths required.
a Finalbuilder project (much easier than a batch file)
an msbuild script (never done this myself but I assume it would be possible).
One solution for this issue is to be more discerning about what parts of the DPROJ (and also DFM files) you allow to be checked in.
You don't mention what version control system you're using but TortoiseHg has a hunk selection feature as part of it's commit process which lets you select individual lines within a changed file to be committed and still leave other lines uncommitted.
I use this method to never check in junk changes from the DPROJ (such as changing the active config from RELEASE to DEBUG) and the DFMs (e.g. changes to ExplicitHeight and ExplicitWidth properties).
The only reason i can think of to NOT version control DPROJ files is if, like the JCL, you can regenerate them as part of your build process. The JCL is a class library (code-library) not an application, and it targets multiple versions of Delphi with differences in their .dproj files. In fact, versions of delphi prior to 2005 didn't use .dproj files at all.
Later version of Delphi XE4, 5, 6, and XE7 are very stable constructing the .dproj XML files. I have no complain using git to version .dproj and .groupproj files. Updates to these files using the IDE editor result to expected neat and clean changes only.
I'm moving frequently between D7 and D2009 with library code that works with both.
For ease of going both ways, I'm routinely deleting all the D2009 additional files that get created, eg: *.dproj etc, such that on entry to D2009 I'm only ever taking D7 files.
This is nice because D2009 automatically makes a *.dproj, *.dgroup etc and apart from a notification on entry to D2009 that each project has been upgraded you can build immediately.
I have two identical machines, each with D2009 on them.
The 'good' one does what I've listed above, creating an upgraded project with the default build configurations 'base', 'debug' and 'release'. Looking in these, I can see my options copied from the Delphi 7 *.dof file (eg compilier options and output directory etc).
On the 'bad' machine with identical D7 projects supplied to it, although it 'upgrades' the projects it does not import the compiler options and output directory settings.
I've not fiddled with build configurations at all.
I can manually import a set of options saved on the good machine, but this is tedious and I'd like to find out why the 'bad' machine behaves in a different way.
Is there a 'master' build configuration that might now have a time/date that makes D2009 think I want that instead on a default upgrade?
I've just come across this exact problem.
In my Drag/Drop components, although I support Delphi 5 through Delphi 2010, I only distribute the dof files. I do this to avoid having to keep the dof and dproj files in sync. Now all of a sudden the search path setting from the dof files are not being exported to the dproj files.
The solution I've found is to strip the dof file of everything I don't need:
[FileVersion]
Version=7.0
[Directories]
OutputDir=.
UnitOutputDir=.
SearchPath=..\..\Source
With this change the dof file is imported correctly.
I haven't had time (nor reason or motivation) to investigate precisely which entry in the dof file that is preventing the SearchPath from being exported.
Ok, just a few questions, you have two machines the good the bad (and not the ugly). The good creates a valid 2009 project from the 7 project. But the bad one misses the compiler options and the directory settings.
At first, are you sure you have provided the .cfg file? This one is needed for this information.
Next, which order are the delphi versions installed. If the newest version is installed before the oldest, there can be some problems. Installing them in correct order gives no problems. (I have had 6, 7, 8, 2006, 2007, 2009 on the same machine without problems).
You said that the problems happened "suddenly". Can you recall what has been changed on the bad machine just before the problems started?
If you have the time, you can try to reïnstall anything.
Hope this helps.
Do you have relative paths in your projects? It seems that D2009 (or the BDS ide in general) reacts slightly different with respect to the work-directory used to resolve partial paths.
Sometimes when you file->open a file, all relative paths are suddenly relative to the path of that opened file. This state also seems to be more persistent.
To exclude such problem, open a file from the respective .dpr/.bdsproj/.dproj dir for each project of your projectgroup and do a build.