 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWordDirectoryUser Groups Related Topics Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ... |
MS Office Forum / Word / Mailmerge and Fax / June 2007Mail Merge Label Macro w/Russian Text
I am currently creating part identification labels in Word by pulling information from various Excel spreadsheets via mail merge. I have managed to automate this with a macro with the exception of one problem: I have used the vrtSelectedItem command to prompt the user for an excel sheet to make labels from. This works well until you encounter a spreadsheet containing Russian text. This results in the data on the label being displayed as ???????. I have tried setting the language to Russian in the word document, but with no success. All of the other settings in windows allow the proper display of Russian text and I'm using a unicode font in the labels. If anyone has a solution to this problem, it would be greatly appreciated.  SignatureBWB Which language version of Windows (and, if different, of Word and Excel) are you using? Which version of Word/Excel are you using? If you are using Word/Excel 2000 or earlier, I do not think you will be able to see Cyrillic characters unless Windows itself is a "Cyrillic" version of Windows (sorry, I'm not even sure there was such a version when Word 2000 came out) If you are using Word/Excel 2002 or later, you may be able to see Cyrillic characters, but only if Word is connecting to the spreadsheet using the default connection method (OLE DB). And even then, I cannot be sure that it will work as I imagine it does. Peter Jamieson >I am currently creating part identification labels in Word by pulling > information from various Excel spreadsheets via mail merge. I have [quoted text clipped - 12 lines] > > If anyone has a solution to this problem, it would be greatly appreciated. I'm using Word and Excel 2003 Professional and I'm not sure of the language version. Since it was obtained in North America, I'm guessing its English. The excel file I'm reading from looks something like this: Quantity наименомание Part # 200 ьолт 55R 100 контргдйкд 46Р . . . . If there is no way to do this via mail merge, is there any other way to automatically generate labels in Microsoft office. (I'm not very knowledgable in the VB programming language) SignatureBWB > Which language version of Windows (and, if different, of Word and Excel) are > you using? [quoted text clipped - 28 lines] > > > > If anyone has a solution to this problem, it would be greatly appreciated. I think your problem is that ???????????? is not being recognised as a valid mail merge field name. As it is the data in that field that is probably more important, I suggest that you replace it with Description as that is what I believe would be the translation of the Russian word if it had been spelt correctly. SignatureHope this helps. Please reply to the newsgroup unless you wish to avail yourself of my services on a paid consulting basis. Doug Robbins - Word MVP > I'm using Word and Excel 2003 Professional and I'm not sure of the > language [quoted text clipped - 55 lines] >> > If anyone has a solution to this problem, it would be greatly >> > appreciated. > Since it was obtained in North America, I'm guessing its English. I'd agree. OK, I copied your data into an Excel 2003 spreadsheet here and created a simple Word 2003 Mail Merge Main docement using that as a data source, and it all seems to work. So e.g. I see { MERGEFIELD наименомание } and the field result is as you might hope from the data.. I though it might be a font-related issue, but the font I'm using is the default Times New Roman. In other words, as long as everything's on its best behaviour, Word seems to do the right thing. So my best guesses are... a. Word 2003 is not connecting to your spreadsheet using its default method (OLE DB): older methods would almost certainly return the "???" you are seeing on an English-based system. b. your mail merge main document is using a font that, unlike Times New Roman, does not support the Unicode Cyrillic characters. Actually my best guess is (a), in which case I do not know what is wrong, but as a temporary workaround, I would probably try to a. select the necessary data in Excel (probably not more than 63/64 columns) b. Edit Copy, then in Word, create a new documnet, and Edit|Paste c. See if the data looks correct (i.e. Cyrillic characters have not been replaced by "?" or other characters) d. See if you can use that as the data source for the merge. Peter Jamieson > I'm using Word and Excel 2003 Professional and I'm not sure of the > language [quoted text clipped - 55 lines] >> > If anyone has a solution to this problem, it would be greatly >> > appreciated. I did much the same, only using a different font. Interestingly the Russian fields came into the document already converted to a font with Cyrillic characters (Arial). When the field is toggled to show the construction, the field name is made up of boxes, but the font is the non-cyrillic underlying font. Change that font to Arial and the cyrillic characters pop back into view. It shoukd be possible to force this behaviour by formatting the field with a font with the extended character set and apply a \*charformat switch to ensure it sticks? Signature<>>< ><<> ><<> <>>< ><<> <>>< <>><<> Graham Mayor - Word MVP My web site www.gmayor.com Word MVP web site http://word.mvps.org <>>< ><<> ><<> <>>< ><<> <>>< <>><<> >> Since it was obtained in North America, I'm guessing its English. > [quoted text clipped - 96 lines] >>>> -- >>>> BWB When I simply run a mail merge in word without recording it as a macro, the russian text will display as required. It is in the following steps where the problem seems to arise: 1.) I record the mail merge as a macro (the merge works fine during the recording). 2.) I modify the macro to prompt the user for an excel file to read from (all the excel files are identically formatted with identical headings) 3.) I try running the macro and select a different excel file to read from 4.) The mail merge executes It is here where the problem occurs. All the english text appears in the proper format no matter what excel sheet I am using. Thus I am guessing it is the macro that is the cause of the problem. All the settings for language and font in word appear to be working properly. SignatureBWB > I did much the same, only using a different font. Interestingly the Russian > fields came into the document already converted to a font with Cyrillic [quoted text clipped - 107 lines] > >>>> -- > >>>> BWB Been away, will pick this up in a day or two. Peter Jamieson > When I simply run a mail merge in word without recording it as a macro, > the [quoted text clipped - 130 lines] >> >>>> -- >> >>>> BWB OK, a. Did you try the suggesiton Graham made, i.e. use Alt-F9 to show the field codes, then format { MERGEFIELD "name of your cyrillic column" } with (say) Arial and change it to { MERGEFIELD "name of your cyrillic column" \*Charformat } ? I had another look at this and cannot currently see what is going wrong (in other words, recording the macro, then using another workbook/filename works OK here. However, it is just possible that Word is actually opening the file using one method (OLE DB) the first time around, but using ODBC the next time around. I'm trying to think in what circumstances that might happen, but it would help if you could post the code of your modified macro. Also, do you see additional dialog boxes when you try to open the sheet specified by the user? Peter Jamieson > When I simply run a mail merge in word without recording it as a macro, > the [quoted text clipped - 130 lines] >> >>>> -- >> >>>> BWB |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.