|
|||
|
|||
| Moderated by: Renate.Reinartz, Markus.Kreisel, Jaakko.Salmenius, Ilkka.Salmenius |
|
||||||||||||||||
| Stopping auto load of DLL - Usage - Three simple steps to localize - Technical Support (You need to be registered at the forum to write) - .NET, Delphi, ... - Sisulizer Localization Tool Support | |||||||||||||||||
| Author | Post | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
|
Jacob Pedersen Member
|
Per default an application loads avaiable DLL. However I only build these when I build retail version of modules. If an old DLL is present and automaticly loaded, I get runtime error 217 even before the first line of my Delphi 2006 project file is executed. How do I take over control of loading DLL's? Because I only have them embedded in retail builds and extract them when needed. Tnx
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Ilkka.Siikanen Administrator
|
Do you mean localized resource DLL files (like MyProgram.FI or MyProgram.JP)? You shoud delete those files or move to another directory. regards Ilkka Last edited on Mon Mar 19th, 2007 06:35 am by Ilkka.Siikanen ____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Ilkka.Siikanen Administrator
|
During development time it is better to build localized EXE-files (which is the default setting). In that way the localized EXE files will be builded into own directory and the original is allways working. When you release your software, you can build localized resource DLLs. Ilkka Attachment: Delphi.PNG (Downloaded 24 times) Last edited on Mon Mar 19th, 2007 06:35 am by Ilkka.Siikanen ____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Jaakko.Salmenius Administrator 
|
By default Sisulizer creates the resource DLLs into sub directories. For example Program1.exe -> de\Program1.DE VCL can not find them there because it tries to look for .\Program1.DE It might be unlogical that Sisulizer creates them to sub directory but there is a good reason for that: The EXE and resoure DLL must be perfectly in sync in order them to work correctyl. If resource DLL is based on previous build it is likely that the resource ID have been changes and your application is going to crash. This is why SL creates them to a sub directory and you have to manually copy them to the EXE directory when you test them. However you have to remove the resource DLLs or let SL to update them if you recompile you EXE and you have changed your source code. You can also make SL to create resource DLL in to EXE directory by using the following settings. Jaakko Attachment: untitled.PNG (Downloaded 24 times)
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Jacob Pedersen Member
|
No you misunderstand me. Let me take an example: A customer has an EXE file which has embedded DLL's; Project.DE and Project.DA. Now these two files are extracted as files and loaded at runtime. Now later on the EXE file is updated to a new version which then means a new embedded DLL needed to be extracted. Problems: 1. We update exe files while users are running it (by renaming the old one). They all have exe files run from same folder. That means a user cannot change to a language loaded by the old EXE (DLL is old and does not match). This I have handled with a MD5 check on embedded DLL compared with DLL on disk. If different it tries to extract it. If not possible, language change is not possible. 2. When running new EXE, it (Windows?) automaticly loads the existing resource DLL from the disk. This DLL is the old version and sometimes it gives errors and other times, strings are totally shuffled. Not until I change the language to force it to extract the DLL, it gets correct. Ofcourse extracting the new language might not happen right away, since DLL's are locked by other users until all have exited EXE or are not using that language. So I need to stop it from auto loading any resources. I need total control over this to ensure correct version is available and loaded at runtime. So it should be loaded with original translation even if DLL's are available. When user logs into the system he has a preferred language which is then loaded, this is the point where DLL is extracted and loaded if needed. He can also change it via the mainmenu in the application. Same code is called to extract, load, and reset all forms (see my other post about the problems here). A bad solution I can see is to load and extract dll's to a temp folder. This means that if application crashes (which it does alot) there will quickly exist a lot of orphant dll's. Also it will need to be extracted at every load which is a waste of time and resources. So I would be sad to go down this road. Thanks
|
||||||||||||||||
| |||||||||||||||||
| |||||||||||||||||
|
Ilkka.Siikanen Administrator
|
I have been finding a way stop autoload, but with no luck. I'll keep looking. Ilkka
____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
|
|||||||||||||||||
|
Jaakko.Salmenius Administrator
|
Hi Jacob, There is not way to prevent VCL loadeding a resource file (except making sure that it does not xist on the same dir as EXE). However you can change the loaded resource or drop it alltogether. Here is a piece of code that we use in one of the initialization section to check the current UI language. The code loads the active language (if not automatically loaded by VCL) and check if the version resource matches. If the version resource does not match it shows an error that tell that the resource is out of sycn and can not be loaded. In that case it forces the application to use the original (English) resources. Also if the active language is English the loaded resource (if any) is dropped. code := LaCore.Languages.UserInterface; if code = '' then begin code := LoadedResourceLocale; valid := DoesResourceFileVersionMatch; end else if code = 'EN' then begin SetNewLanguage(''); valid := True; end else if DoesLocaleResourceFileVersionMatch(code) then begin SetNewLanguage(code); valid := True; end else valid := False; if not valid then begin SetNewLanguage(''); // Do not resource this JuInformationDlgFmt( '"%0:s" resource DLL file does not have the same version number'#13#10 + 'as the "%1:s" application file.'#13#10 + 'The application can not run correctly because the old resource DLL may cause the application to crash.'#13#10 + 'Close the application, delete or update the resource DLL file(s), or'#13#10 + 'press OK to use original English resources.', [GetLanguageFile(Application.ExeName, code), Application.ExeName]); end; You can find the above functions is <sldir>\VCL\LaResource.pas unit. Best regards, Jaakko Last edited on Sun Mar 25th, 2007 06:21 am by Jaakko.Salmenius ____________________ http://www.sisulizer.com - Three simple steps to localize |
||||||||||||||||
| |||||||||||||||||
| Current time is 08:29 am | |
| .NET, Delphi, ... - Sisulizer Localization Tool Support > Technical Support (You need to be registered at the forum to write) > Usage - Three simple steps to localize > Stopping auto load of DLL | |
Sisulizer software localization tool - Three simple steps to localize
