I have VS2003 project which i converted to VS2005. Everything works however the project has resx files which only opens in VS2003 but not in VS2005. While looking at resource files it looks like the files are missing Designer file in VS2005. Is there anyway to create these designer file in VS2005 easily other than adding new resource file and adding texts in new resource file manually.
I have tons of resource files with bunch of values in there. Just want to save time from retyping all those values again.
Solution: Here is what i did to save time. First imported resx xml content in Excel application. Excel was smart enough to put name and value in separate columns. Copied those name/value pair and pasted in new resource file in Visual Studio. Baam. Done. :)
Related
Hello programmer friends, I have learnt a lot from this excellent site, and maybe there is something else that I can learn.
Well, I have taken over a delphi 7 project from someone else, made a few minor changes on it, mostly if then clauses, I didn't change the main structure at all, just a few changes, I did't even add any variables. The problem is, it used to work perfectly, but now we are having APP crash reports. I deleted whatever I added, deleted the whole folder actually, re-copied it from the usb disk again, compiled it the way it is, and we sometimes have APPCRASH reports again. Even if I compile the original version, we receive the errors.
I made a search in the folder and I found out that the folder includes a DSK file which is full of folder paths about the other computer (I mean the paths defined in the DSK file belong to the other computer, not mine!)
What happens if I delete this dsk file? How can I re-create it again with my folder paths? Is it possible that we have these APPCRASHES because of this DSK file?
Here is a photo I've taken after a CTD and I tried to debug..
The .dsk file is only used by the IDE (see below for details), so it cannot possibly be causing your APPCRASH reports. It is only used by the IDE at designtime to save and restore your desktop information; it is not in any way included in the executable or used at runtime by your application.
The .dsk file simply saves the desktop when you save the project. It saves the currently open editor tabs and the files each contains, in the order that the tabs are arranged, and saves the state of each tab (code or form editor, for instance).
The Delphi 2007 help file says
Saves the arrangement of your desktop when you close a project or exit the product. When you later open the same project, all files opened when the project was last closed are opened again, regardless of whether they are used by the project.
The help for Delphi 10.1 Berlin shows more is saved now:
Autosaves or updates the project desktop file (.dsk file extension) when you close the project or exit the product.
The <myproject>.dsk file records your current settings for:
Desktop layout
Breakpoints
Watch items
Files currently open in the IDE
When you reopen the project later, the .dsk file is read, and your desktop layout, your breakpoints, and your watches are all restored. Also, all files that were opened when the project was closed are opened again, regardless of whether they are used by the project.
When Autosave Project desktop is disabled, any existing project .dsk files are read when opening the project, but the .dsk files are never updated. This causes the same set of files to open with the project until the .dsk file is manually deleted from disk.
You can safely delete this file. The only consequence of doing so is that you will lose the contents of the file, which means the next time you open the project you'll get just the default files (the main form and code unit) or project file opened in editor tabs. If you have Save desktop turned on, the IDE will recreate the file (using your currently opened editor files) the next time you save your project.
In C++Builder XE5.
My understanding is that the binary file MyProject.res (which is created by the compiler in the same directory as the .cbproj file) contains compiled versions of the program icon and the project version details (although mine also seems to contain an XML manifest).
But this info is also contained in the .cbproj file and the .ico files; and if I delete the .res file then it seems to get recreated exactly was it was next time I open the project.
So is it safe to mark *.res as not being in source control? (I use git). And/Or is it possible to have it generated in the same directory as the object files instead, so it's not mixed in with the source?
(This certainly wasn't safe in C++Builder 5 - if you deleted the .res file then it complained it couldn't find it, and you lost your icons).
Update: Does this also apply to the .tlb file? This seems to be compiled based on the .ridl file, and if I delete it then it is automatically regenerated.
C++ Builder 6.0 and later will recreate RES files if deleted. I treat them as other temporary/build files (like OBJ files) and do not put them in version control software. I do have nightly backups that include all of these files though, which I think is still good practice.
I am not sure about TLB files. I would temporarily delete (aka-rename) one and see if it gets recreated to the same state. If so, should be same as RES files.
This does not hold true for 3rd party libraries though, if all you have is compiled resources. In that case, I still do not place in my version control though, since I am not going to be modifying them. I just have my backups.
For what it's worth, the TFS source control defaults are to exclude *.res but include *.tlb.
So you should expect *.res files to be created by their associated builds. If the build isn't going to be present, then the *.res file should be included.
I suspect that you're right about *.tlb files being built as well, but perhaps TFS doesn't exclude these on default because the extension isn't entirely unique to OLE type library files alone.
When I open a Delphi 7 Project in Delphi XE2 and open the Project Option I get an error:
"Unable to set Icon: Cannot open file "........\AppName_Icon.ico".
The system cannot find the file specified".
I also notice that the Version info of the Project is missing.
The Delphi 7 project has .Res file that has the MAINICON along with the version information stored.
Why is Delphi XE2 not able to use this .Res file to retrive the MAINICON & Version information.
Also if I try to compile the application in XE2 I get an error -
[BRCC32 Error] MtxReq.vrc(2): file not found: MtxReq_Icon.ico
The MTXReq.vrc file (a new file) is created and the MtxReq.res file is deleted.
Why is this happening? I don't want to loose my project icon and version settings from .res file.
Is there a way to force XE2 to use the .res file and not delete it?
Any help will be greatly appreciated.
Sorry I can't post a comment yet (need more repotation points) ...
Warren - here the reponse to your question (Wouldn't just deleting your .dproj file and keeping the .dpr only, have been faster?)
I deleted the .dproj, .dproj.local
Opened the .dpr in XE2 and it recreated the .dproj file.
It brough back the icon from the .res but I lost project version info. Only File Version and Product Version info got migrated but lost all other versioning info. (This is because of the default manifest file).
I then tried what I explained in Step 1 of my solution.
I open the .dproj file in notepad deleted the tag entries under and reopened the .dproj file and all my version info now was recovered. The problem here is the $(BDS)\bin\default_app.manifest.
Also I noticed that Version info is stored in tag under the tag in the .dproj file and once you delete the default manifest entries, the IDE pickups the version key information correctly from the .
So basically by deleting the .dpr file I skipped the step of extracting and adding the .ico file to the project, but had to edit the newly created .proj file and delete the entries for default manifest to retrieve the version info. (another solution would have been to manully add the version info and saving the project. I did not try this)
Update 2015: Remy's idea of recreating .DPROJ files carefully by hand, is excellent advice and should be considered first, even though my answer is marked accepted.
Delphi versions prior to XE2 used resource files as an INPUT and an OUTPUT in the compilation process. For example, your delphi 7 project icon is embedded in that .res file, which you "want delphi xe2 to use", however, that's problematic in delphi 7, and now flat out impossible in XE2. Instead you now treat the .res file as a pure output artifact, the same as executable files. Don't bother checking .res files into version control any more, and don't try to pretend that the .res file is the place where you permanently store your icons. It's an output file produced automatically by the compiler, as it always should have been.
If you are a modern developer, the old way Delphi 7 worked might have annoyed you (it sure annoyed me) because you have the interesting and unsolveable question about what to do for version control: Do you check in the .RES file, or don't you? There were drawbacks to both approaches, and the fact that .RES files are now output artifacts only in XE2 is for the best. So learn to live with that.
Now that XE2 supports icons not only for a PC but also for a Mac, it must handle things differently, and they have cleaned this up. This is the origin of the problem you're seeing with the .ICO file. I have seen exactly the same error, and I have ignored it, and simply added the icon back to the project after it has otherwise been converted.
Converting a delphi 7 project (.dpr and .cfg) to Delphi XE2 is not as big a problem as the conversions between various levels of .dproj files -- each version starting with Delphi 2005,2007,2009,2010, and onwards has implemented changes in the dproj format. When problems occur with converting these projects, I do not do as Remy suggests, because it's a waste of time. What I do is DELETE the DPROJ and let it convert up from a .dpr file only.
But Remy's advice to start from scratch has many advantages, including that you may simplify your project layout.
Anyways, here's what you do:
Ignore error.
Add icon to project yourself.
Continue merrily along, and don't worry about the deletion of the .res file, that's intentional, and for good reasons. A new one will be created whenever needed. The filename of the .ico file on disk will be read by using the contents of the XE2 .dproj file and compiled into the .res file, as it should be.
As is always the case, you should NEVER let the IDE convert a project from an older version to the newer version. The conversion RARELY works correctly. You should ALWAYS create a new project in the newer IDE and then add your existing source files to it as needed.
Thanks everyone for your inputs and suggestions.
After I submitted my posting, I tried these steps to resolve the .ico issue and the missing Version issue/version info carry over issues :
Step 1. Edited the .dProj file and removed the reference to default_app.manifest related entries under tag (My project platform is 32 bit)
I deleted all tags under this except tag related to namespace System.Win;Data.Win;Datasnap.Win;Web.Win;Soap.Win;Xml.Win;Bde;$(DCC_Namespace)
Without this my application was always showing the version info as 1.0.0.0 and ignoring everything else that I had specified.
(I am not sure if this is a right step but it solved my version info issue. There may be a simpler/another solution for this...)
Step 2. Extracted the ico from the old .res file, named it and added that .ico file to the Project from the Project Options.
the physical .ico file is the the projects folder and will be checked in source control (VSS in my case).
These two steps bought me to what I needed and then I can modify the Version number and compile the project.
From this point on there are no issues.
These were much simpler than the total conversion/migration I had to do for my applications from D7 to XE2 - Unicode conversion, migrating customized Raize 5 componets to Raize 6, Turbo Power, Virtual Tree View, Hypergrid etc. etc. etc... Luckily I found XE2 versions of all these components.
Is there a rule of thumb that .pas, .dfm and .dpr files should not be removed?
While opening/working with concerned project files ,Unit1.pas,Form1,Unit1.dpr etc are automatically created by the IDE in the same project-folder.As they were not related to my proj,I inadvertently deleted them.Will that cause any issue?
Further should the same project be saved with a new name every time one saves it?
Like PfojDel.dpr
edit then save as PfojDel1.dpr
edit then save as PfojDel2.dpr etc
Kindly help
Thanks and Regards
Vas
Your first question's pretty straightforward. Any file that you need to compile into your project needs to be present on the disc. Anything else can go.
As for changing your project file name, that's a big hassle. Sounds like you're trying to keep a history of your changes. If so, I'd look into version control if I were you. TortoiseSVN makes it pretty easy to create a simple source code repository, either on your own hard drive or a networked system, that you can check changes into to keep a history.
See http://delphi.about.com/od/beginners/a/aa032800a.htm for an explanation on all most file extensions you come across when developing a Delphi application.
The dfm file contains the component information for the form (or data module). The dpr is the basic pascal program file. It is also the base of the project (normally contains the list of files in the project).
Deleting them is not a disaster, but you need some time to recreate them (specially if the form is big). But if you have the choice, do not delete them.
The dfm files are created because they contain the information you provide with the form designer (position of controls and the value of their published properties).
If you have renamed your project, you can delete the other files without problem. This is also true for units that are not used anymore.
You don't have to use a different name every time you save the project. If you want to keep track of changes, use source control. (Every wise programmer should use source control and backup the files frequently).
Under normal circumstances you shouldn't have any Unit1/Form1 files on your system. The first time you save/compile/run a project with a new file the IDE will prompt you for the filename and location.
If you have a file named Unit1/Form1 then it would indicate that you have a unit or form which hasn't been given a name, but it may still be used as part of your project. If it is used as part of your project then it is not safe to delete it. The only way to know if is used is to go through each of the uses clauses in your project, or to use an automated tool to do this for you.
We are in the process of localizing our windows forms application.
We are using the approach where we set the localizable property to true and generate one resx file for one locale.
The problem is we have 20 forms, each to be localized in 3 languages, so there are 60 resx files. Each form shows 3 resx files along with cs and designer and default resx file.
It would be if there was a neat way to bundle all the resource files of 20 forms in a language specific folder. How to do it?
Since .net generates one satellite assembly for one language, after the assembly is generated after build process, can I move/delete the resx file?