I've been successful in using form.location.resx files to localize the strings associated with form controls. However, I don't see how to (safely!) add strings to the .resx file(s) and then access them for such things as message boxes.
If I try to add a string to the .resx file using Visual Studio (2017), I get a warning dialog pop-up telling me that this could corrupt the "project item" (form) or my changes could be lost if I change the associated form.
Also, if I use this method, would I need to manually add my strings to each language file separately?
Alternatively, I could create a bunch of Labels to the form with visible=false and then edit their strings in the .resx files and use something like:
msgbox(LabelSampleMessage.text,MsgBoxStyle.Information,LabelSampleMessage2.text)
But that seems like it would be massively inefficient.
For Windows Forms, the best way to do this is to go into the Designer and set the Language property on the form. This will create a formName.Designer.languagecode.resx file for you. Then you just edit the Text properties of the controls. The changes will go to the resx file for the language you're editing. You can even have different layout and control spacing for each language (useful if a label is short in English but translates to something long in German).
For MessageBox messages, you do the same thing with the Resources.resx file. Just put all the messages in your Resources and duplicate the resx file for each language. Then use the Resource editor to translate the message in the other languages. You can then look up the message using My.Resources.Default.SomeMessageKey
#David: Note that I'm the author of a commercial ".resx" localization program for VS (in the interest of full disclosure). Yes, dwilliss is correct, though the names he used are a little off. For Windows forms, you can't manually update the ".resx" files yourself (directly), hence the warning from VS (don't know why they did things this way - go figure). You won't get that warning for strings you put in "Resources.resx" however. Just manually add "Resources.[LangCode].resx" and update it on your own. You have to add the keys yourself (again, no warnings). You can then simply access each string via the static properties seen in the "code-behind" file "Resources.Designer.cs" (one static property exists for each string you add). These are what MSFT calls "strongly typed" resources. If you access, say, "YourApp.Properties.Resources.SomeMessage" for instance (from "Resources.Designer.cs"), it will be returned in whatever language is currently set in "System.Threading.Thread.CurrentThread.CurrentUICulture" (assuming that language's satellite assembly is installed of course). This is all a pain and highly error-prone for other reasons as well, hence the reason I wrote my program (shameless plug but MSFT's way does work, though it's very primitive for handling translation in general - a professional organization relying on an external translator will save a lot of problems and $ in the long run by using a 3rd-party translation program, not mine necessarily though it would be my tool of choice of course, but anything is better than handling it manually).
Related
I have seen Use a single source file for many QtDesigner forms, which is the gist of my question also, - but it simply recommends:
My advice is to use it as Qt way. Use seperate classes and seperate files for each form. This approach is better.
However, I would like to specifically know - is it possible at all to define multiple forms (say, a "Main Window" and a "Dialog with Buttons Bottom") in a single .ui file, and work with them in QtDesigner?
Basically, for an application of mine, I use QtDesigner .ui file to design the MainWindow, and load that from Python (PyQt5) - and it works great. Now, I'd just like to add a window dialog raised on a click of a button, and I'd also like to use QtDesigner for it, but I wouldn't want to maintain two .ui files. I'd imagine, once such an .ui file (with multiple form definitions) would be loaded in Python, the Python code would just set all forms other than QMainWindow to hidden, and then manage when they are shown appropriately.
(I use QtDesigner on and off, so I do not know it very well - however I recall there was some stuff that QtDesigner couldn't do from the UI, but one could do manually in the .ui file, and after such changes, QtDesigner could still deal with them. So, if there is a way to do this - even if it is not fully supported in the QtDesigner UI - I'd love to know about it, or have a definitive answer that it is not doable).
tl;dr
No, you cannot.
Why not?
UI files are intended for individual widgets (it doesn't matter whether they are intended as top level windows or not) and their possible children.
While I can understand your request, it seems more related to a "project" concept than an UI one. That's not the intent of Designer, which cannot imagine the possible extent of your project; and even if that was the case, it wouldn't be very practical: what if your project could potentially have hundreds of windows? Suppose that you have a main window, open your program, but then you decide to close it: your program would be loading hundreds of windows, but use none of them, causing an unnecessary overhead in the program loading.
The concept is similar to the modularization of OOP: not only you just "load" what you actually need, but you also should "split" the project in different files (modules, not unlike python modules) for better maintenance , reusability and overview. What if you want to have two separate "main" UI files for some reason, and, coincidentally, they use a similar dialog? You should copy that dialog every time, and if at some point you forget that step, you might even cause your program to crash as it's trying to access objects that don't exist or have been just slightly renamed.
Furthermore, some interfaces can be really complex, and automatically loading them at startup would be pointless: if you're using the uic module, you're requiring unnecessary parsing of the whole xml tree of the UI, and that would be for every time a new instance for a window from that file is required.
Maybe, someday, developers at Qt will decide to allow "projects" in Designer (which is probably what Qt Creator does, but I've never used it), but ui files will still be individual, as they should.
So, don't worry too much, it's more a question of habit and a slightly annoying aspect: if your project is well conceived, and you also properly name your files, it won't be a major problem and it will have its benefits anyway (even if you don't consider them as you could).
PS: yes, UI files are XML files and can be edited; you could even create/edit an UI file and do things Designer couldn't. But that's just an "unexpected feature" (or smart hack), for which you can never be always sure about the outcome. In future (or just different) versions the parser could be[come] more strict, with the result that your UI becomes completely unusable. That's not unlike editing pyuic files: the programs that use them expect a known behavior (the XML output of Designer), and common, accepted usage. As the recent pyuic file headers (which, I'd like to mark, was added after a personal suggestion of mine) report: "Do not edit this file unless you know what you are doing" ;-)
I created a few resource files for different languages. (E.g. resource.resx, resource.nl-NL.resx etc)
At this moment I only can see the result with the phone emulator. (By changing the language setting in the phone emulator)
For the design phase I want to see the result in different languages at design time. For example Dutch. (Or even better, some pseudo language)
It looks like Visual Studio (2012) and Blend both use the default resource file. (resource.resx)
Is there a way to use another resource file?
I could not find a good solution for this, so I did a very ugly thing. Works but is no fun at all.
I renamed the resource files so that the language I wanted to see had no language suffix (and the original one had a suffix that I know I will not use).
Some caveats:
The original language-neutral resource file has a 'custom tool' property of 'PublicResXFileCodeGenerator' (or equivalent). The resource file that is the new neutral language needs this property. It must be removed later on when we go back to the original situation after testing.
If the language that you want to test did not redefine all strings, you may get some compile-time errors and you need to copy the missing strings from the original neutral resource file.
The only advantage is that there is no need to reboot the emulator to see this language in action.
You can set the CultureInfo property by inserting the following code into the InitializePhoneApplication inside app.xaml.cs
private void InitializePhoneApplication()
{
Thread.CurrentThread.CurrentCulture = new CultureInfo("da-DK");
Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;
This will override the culture, so you don't have to change it inside the emulator.
My app currently reads a script containing instructions on what the app should do next. Think of it this way ---> My app is like an orchestra, and when it is passed sheet music (the script), it knows what to do. The sheet defines what different parts of the orchestra do at different times.
Currently, writing the script by hand is tedious. I want to be able to define chunks, which I can drag and drop from my gui to the script. I was wondering if there already is tools which let you do something like this, or if I should write my own tool.
Basically, when I click on something in the gui, it should insert a template into my plist, which I can tweak.
EDIT: It looks like the ability to create "Property list Structure Definitions" is what I am after. I have tried searching the apple site, but I can't find any documentation.
Two things come to mind:
You don't mention what format the input is in, nor what you want the GUI tool to do beyond letting you "drag chunks". But if you can define your format into an XML schema, then you can use any number of XML authoring tools that customize their interface based on schema. Also gives you the ability to make it easy to let the UI enter parameters/customization, which your script language likely has. Final bonus: you might be able to convert script directly into a plist with a simple XSLT file.
Check out Briefs, which is a prototyping application for iOS apps that has a similar architecture.
I'm fairly new to VB.NET, and I've mainly been doing ASP programming up 'til now, and I have a pretty simple question.
I'm creating a program that will copy a selected file to a selected directory, and I want to store recent files/dirs so that they can be selected from a combo box. I was planning to just create a settings with "files" and "dirs", and just store the strings as | separated values (since that's an illegal file character).
Is there anything wrong with this approach, or are there any better methods?
I think your approach is fine as it seems to be simply a local cache of recent directories. You can persist the data in the application at the module level(create a module with a public object essentially is a global variable) but it goes away when the application is terminated.
This article is using a similar approach to what you were thinking although the example is in C#
I am maintaining an old VB6 application, and would like to include SQL scripts directly in part of the project. The VB6 application should then extract the text of this script and execute it on the server.
The reasons for this approach are various - among others, we want to deliver only an updated executable rather than a complete update/installation package. Hence, the SQL scripts need to be compiled into the application just like a resource file. And, obviously, one has to be able to get at the content from code, in order to send it to the database server.
Does anyone have a good way to do this?
The simplest solution is to just create a VB module with the scripts as strings.
If you want to use a resource file instead, you can do that too. You can associate a resfile with a VB project (I don't remember how to do this directly in the VB IDE but the VBP file supports a ResFile32 parameter).
EDIT: It seems like the issue here is mostly about formatting -- you don't want to store SQL queries as one long string, but formatting the query nicely inside VB is tedious because you have to add quotes, add string concatenation operators to join the lines together, etc.
I would recommend placing the SQL in a text file and formatting it in whatever way you like. Write a script that will take the text and convert it into a VB module. The build process would be modified to always apply this script first before compiling the application.
For scripting, use your favorite scripting language; if you don't have a favorite scripting language, this is an easy enough task that you could do it in VB, C#, or any other language. If it were me, I'd probably use awk (gawk) or Python.
If you want to use a resource (.RES) to store your SQL, go to the menu:
Add-ins > Add-in Manager...
and select VB 6 Resource Editor. Configure the add-in to be loaded and to load at startup.
From the editor add-in, VB provides a simple interface to add resource strings. You will refer to these using the provided constant values. To load the strings at runtime, use the LoadResString function:
Public Const SQL_INSERT As Integer = 101
Dim strSQL As String
strSQL = LoadResString(SQL_INSERT)
(replace "101" with the constant value of the string you wish to load)
Just another thought on your approach. Because I find myself tweaking the program's behavior or UI for customers I might be in the middle of a change that either is not ready or has not yet been tested and approved. So if I have properties that change from time to time, but I want to maintain control of, for instance connection settings to our ftp server, I will create a resource only dll exposing my properties and use a resource file in the dll to supply the values. When my network manager changes something on the ftp server I change the strings in the resource maanger, recompile the dll and release just the updated dll. I'm sure there are many more solutions, but that is how I do it. If you don't think you might have to change your SQL scripts at the same time you are changing you exe this probably only complicates your work. It has worked well enough for me that now this is pretty much standard for me.