Having troubles attaching files with foreign language characters via script

HCL Domino Domino Forum
1

We have an application in which one component has an agent facilitating the attachment of files to a document without necessarily editing that document.

It’s pretty basic script stuff - I prompt the user to select a file from the file system using “NEMGetFile” as documented elsewhere in the forums…

Declare Function NEMGetFile Lib “nnotesws” ( wUnk As Integer, Byval fileName As String, Byval szFilter As String, Byval szTitle As String ) As Integer

fileName$ = Chr(0)

If NEMGetFile( 0, fileName$, “All Files|.|”, “Select File” ) = 0 Then Exit Sub

I then grab a handle to the document backend and richtext field, attach the file, and save the document…

Set rtitem = thisDoc.GetFirstItem( “Body” )

Call rtitem.EmbedObject( EMBED_ATTACHMENT, “”, fileName$ )

Call thisDoc.Save( True, True )

There’s alot more to it than just that, but that’s the gist of the logic.

In any case, it all works very well, as long as the file names use English characters.

Once we rolled the app into countries such as Japan and Korea, the users started attempting to attach files with names like “C:\QUOTE ¿©ºñ±³ÅëºñÆ÷ÇÔ-SA[R 1.0].doc”.

Once that happened, the process failed miserably. I started receiving errors such as “Error 4225: File not found” in the “EmbedObject” line.

I notice that the characters used to represent the file in script (above) differ greatly from those used to represent the file when I view the file using Explorer.

I really want to make the application resistant to this sort of incompatibility.

Is there anything I can use in my script to get around this?

Any information you may be able to provide would be most appreciated!

Cheers,

T.

2

Subject: Having troubles attaching files with foreign language characters via script

One thing you could try, although I haven’t tested this at all, is to translate the string to LMBCS.

You need to define an API and a constant:

Declare Private Function OSTranslateToLmbcs Lib “nnotes” Alias “OSTranslate” (ByVal TranslateMode As Integer, ByVal pInString As String, ByVal intLength As Integer, ByVal OutString As String, ByVal OutLength As Integer) As Integer

Const OS_TRANSLATE_UNICODE_TO_LMBCS = 23

Then you need a function like this:

Function toLmbcs(p_sInBuffer As String) As String

'===

’ Attempts to convert a string to LMBCS.

'===

Dim sOutBuffer          As String



sOutBuffer = Space$(LenB(p_sInBuffer) * 3 + 1)

Call OSTranslateToLmbcs(OS_TRANSLATE_UNICODE_TO_LMBCS, p_sInBuffer, LenB(p_sInBuffer), sOutBuffer, LenB(sOutBuffer))



'-- Convert a string to return

toLmbcs = Left$(sOutBuffer, InStr(sOutBuffer, Chr$(0)) - 1)

End Function

Now try to attach the file in this manner:

Call rtitem.EmbedObject( EMBED_ATTACHMENT, “”, toLmbcs(fileName$) )

As I said, I have no idea if it’ll work but it’s worth a try.

// Ken Haggman, NotesHound.

3

Subject: Thanks Ken…

I really appreciate your response.

Unfortunately, that didn’t work (the string was even more garbled than to begin with!).

However, you have given me a new lead to pursue, and I’ll respond with any progress I happen to make.

Cheers!

4

Subject: RE: Thanks Ken…

Hi,

Can you use the OpenFileDialog method?

I’ve used the same API as you did but I had similar problems with accentuated characters(é,è,ù).

JYR

5

Subject: You’ve nailed it once again JYR

Man, talk about “getting into a rut”!

This is quite an old app that I have just been re-visiting, and that is an even older function that I used to use for file selection.

Thanks very much for taking my blinkers off - I love it when an answer is as easy as that (although it makes me feel stupid for not seeking such a basic alternative myself!).

Cheers mate!

T.

6

Subject: RE: You’ve nailed it once again JYR

it’s a pleasure!!

By the way, any news of that problem? Just curious :slight_smile:

Date

Topic

Desperate to find out what the server is actually doing (Terry Boyd)

JYR

7

Subject: Re: Update on the problem

Geez, I’d almost cleared that horrible memory from my brain, and you had to bring that up!

Man, that was probably the single most frustrating incident of my entire career thusfar, and I’m no spring chicken anymore.

To this day, nobody can tell us definitively what happened.

It was obviously a huge volume of changes in one database (whether they be document changes, deletion stubs, whatever) that needed to be replicated out to our remote users. What those changes were, we have no idea (as we had not made a significant number of data changes before the issue arose).

That said, there was no indication of any network traffic spikes. All we know is that, as soon as ONE remote user started to replicate with the ONE database, everything ground to a halt.

As soon as the user’s replica was up-to-date, the replication for that user returned to normal. Of course, that process re-occured for almost 900 users around the country!

In the end, the problem slowly just disappeared.

IBM could make nothing of the volumes of logs - both server and client - and NSD’s we supplied. We had them onsite several times, all to no avail.

Whether it was a corruption, deletion stubs, replication issues, or whatever - I don’t think we’ll ever really know now.

What I am thankful for is that the issue has passed. I will always wonder what caused the issue, as understanding leads to prevention of a reoccurence.

I will always be extra cautious in this site, and changes are being made in VERY small doses these days to the database in question.

Thanks for asking… now it’s back to my therapy!!

Cheers!

T.