I just needed a break, was working on yet another conversion (this time a scottish clinic with its outcast unit in Northern Ireland), so we just went and bought a new mirko. Nothing really wrong with the old one, except that it was loud, and when the magnetron starts it makes a kind of a bump sound, something like when a piece of cloth goes taut in the wind. So we delegated it to a lighter duty - it goes to Čankovo to warm up lunches and make coffee. The new one, from Gorenje, at least has neat clean design and operates more smoothly. Again, no keypad, just two dials - for the percentage of active time (aka strength, which can't really be regulated on a mirko) and the mechanical timer. And for the first time since 1980, the door with a good view inside. Progress was made, finally. It was always either the mesh too fuzzy, light too dim or both. And this is our seventh (or eighth, if we count the one we bought for the girls in Richmond).
Also bought a couple of frying pans - one deep for Karađorđeva (thinking of Milan), and a smaller one for eggs. The old hens are still laying eggs, but there are only seven of them and they are three years old and we get 3-4 eggs a day, sometimes less. New hens should be coming soon.
More fun with Firriver - this time a second clinic in Poland (one in Kraków, one in Sczecyn) has trouble with non-western characters under software made by m$. Here are excerpts from a draft text (the final results of which went into the new wiki)
Things tried so far:- converting the .csv to codepage 1250. It is converted, as observed when the csv is opened in Notepad, but it's all wrong when opened in Excel or pulled in for merge in Word. It's either the Notepad displaying it as 1250 (because the 168.192.0.8 workstation is set to CP 1250 already so it defaults to it) or the Office apps are applying some kind of blind conversion, where Ł becomes the £ etc). At some point we did observe that the mailmerges which were created in Polish (i.e. not reused from anything based on an English document) did work correctly). The few documents we tried seem to have all Polish properties and yet display the characters wrongly, but it would require digging into document history to find out.
- setting the codepage for non-Unicode apps to 1250 - this is already so on the 168.192.0.8 workstation and the Crystal reports still show the wrong characters. This works on a couple of machines where we tried it (including one set to Bulgarian) but these have Windows 7 - it's possible that something in the handling of non-Unicode apps has changed in the latter editions of Windows. On this machine it simply doesn't, Crystal reports still convert the characters.
- we're presently investigating two options - one is to encode the .csv files for mailmerges in UTF-8, which seems to be automatically accepted by Word with any characters. The attempt to tell Word which codepage to use (which is an option when manually merging, there's a dialog to choose) is abandoned, m$ doesn't provide a programmatic way to do that. The other will be to try to export data into Crystal via xml instead of dbf - the dbf may have contain the correct codepage but Crystal doesn't read it.
a draft text (the final results of which went into the new wiki)23-mar-2017
it works with xml (set to utf-8) but on Kraków server it won't load xml because the crdb_adoplus.dll requires the .net 2.0 runtimes and by default newer Windowses are loaded with just 4.0 or later. There's a switch for .net apps in app.config
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>but this is not a .net app and there's no app.config file. So either install .net 2.0 on each workstation or find a way to activate this switch by other means.
Things tried so far:- converting the .csv to codepage 1250. It is converted, as observed when the csv is opened in Notepad, but it's all wrong when opened in Excel or pulled in for merge in Word. It's either the Notepad displaying it as 1250 (because the 168.192.0.8 workstation is set to CP 1250 already so it defaults to it) or the Office apps are applying some kind of blind conversion, where Ł becomes the pound sign etc). At some point we did observe that the mailmerges which were created in Polish (i.e. not reused from anything based on an English document) did work correctly). The few documents we tried seem to have all Polish properties and yet display the characters wrongly, but it would require digging into document history to find out.
- setting the codepage for non-Unicode apps to 1250 - this is already so on the 168.192.0.8 workstation and the Crystal reports still show the wrong characters. This works on a couple of machines where we tried it (including one set to Bulgarian) but these have Windows 7 - it's possible that something in the handling of non-Unicode apps has changed in the latter editions of Windows. On this machine it simply doesn't, Crystal reports still convert the characters.
- we're presently investigating two options - one is to encode the .csv files for mailmerges in UTF-8, which seems to be automatically accepted by Word with any characters. The attempt to tell Word which codepage to use (which is an option when manually merging, there's a dialog to choose) is abandoned, Microsoft doesn't provide a programmatic way to do that. The other will be to try to export data into Crystal via xml instead of dbf - the dbf may have contain the correct codepage but Crystal doesn't read it.
23-mar-2017
it works with xml (set to utf-8) but on Kraków server it won't load xml because the crdb_adoplus.dll requires the .net 2.0 runtimes and by default newer Windowses are loaded with just 4.0 or later. There's a switch for .net apps in app.config
<startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>but this is not a .net app and there's no app.config file. So either install .net 2.0 on each workstation or find a way to activate this switch by other means.