cp->tra: please have a look at it

The MAPI specification clearly says that lpszFileName in the MapiFileDesc may be
NULL. So this is a Groupwise bug and should be fixed by Groupwise. Isn't
Groupwise a Novell product? Any other application would have to workaround this
Groupwise problem too so the most sensible way is to fix it is to fix it in
Groupwise. OOo2.0 is more robust with regards to MAPI anyway because we are
calling MAPI outside the OOo process so that at most the MAPI calling helper
application crashes but not OOo.

Yes, of course we can fix groupwise - and I'm working on that; however - there
is a large deployed tail of unfixed groupwise' out there - and a belt & braces
fix is  preferable.

Furthermore, as you can see, the fix is simple & painless in the extreme.

I'd greatly appreciate it getting into (at least) 2.0, and preferably 1.1.4 :-)

set target to 1.1.4

This also needs a 2.0 fix, that is different in senddoc.cxx 

retarget to 1.1.5.

mh->tra: do we need to clone the issue for 2.0, is there any risk for
integration in 1.1.x series ?

Bug #i34264# targets the 2.0 development - the patch needed substantial re-work
& I havn't tested it there yet :-)

Michael: can you finish the work for 1.1.5 or should we retarget this issue?

Pavel - this patch is trivial, correct & fixes the bug for 1.1.5.
Yes - in theory this is a G/W bug - however, clearly in order to integrate well
with G/W it helps to be a slightly friendlier customer of this interface.

ie. I'd love to see this patch, as-is in 1.1.5; no re-work is needed or suggested.

I'm quite confused: what is the valid target here 1.1.x or 2.0 ?

The valid target is 1.1.x - it's a trivial patch, that works around a crasher
bug with G/W.

Created attachment 35306 [details]
Patch for 2.0.2

mark type correctly & target at 2.0.3
& re-assign to Tor ...

Hmm, I created a CWS tml03 for this but then when I tried to do cwsadd -a -f
shell (as the http://wiki.services.openoffice.org/wiki/CWS page says, if I
interpret it correctly, I get an error message:

cvs [server aborted]: "tag" requires write access to the repository

Figured out my CWS issues... Fixed in CWS tml03.

I don't know why but tra was chosen a a QA rep for the CWS and he's not working
on this stuff anymore. So I took this over. Unfortunately my first attempt to
test the code ended with a crash in senddoc.exe (of course I didn't test with
Groupwise because I don't have it but I tested with Thunderbird).

Admittedly this was a quick and dirty test (just copy over the binaries from the
CWS into my installation) and I will do another test using the full CWS.
Unfortunately that means we might not be able to deliver this fix in 2.0.3 -
depends on how fast I can set up the CWS build and test it (and of course it
depends on how good the fix is ;-)).

A first question about the code: what is 

sal_Int32 nLastSlash = aFullPath.lastIndexOf('\\');

supposed to do? I assume it should be used to extract the file name from the
path name but I don't see any code doing this. Currently it seems that file name
and path name are identical so you indeed avoid the crash in GroupWise but the
question remains wether your code fools MAPI clients that rely on the file name
being not a complete path. 

I'm not a MAPI expert so I don't know what usually is expected here, so I think
we should test this with some clients at least before integrating it. It seems
to work well with TB1.5 (my crash in the first attempt was caused by an STL
Debug assertion that you only get in "Non Product" builds - something to look
after but most probably not related to your patch).

adding me to cc:

Ugh, thanks for looking at the patch more closely. It needs some more work.
Dunno what I was thinking.

Hmm, there seems to be other problems, but no crashes as such, with an OOo 2.0.2
without this patch and GroupWise. With a 2.0.2 binary from www.openoffice.org,
if I type some random text in a OOo Writer, and select File:Send:Document as
E-mail, it starts GroupWise, but nothing else happens. No crash, no dialog
asking for at lest a recipient, no nothing. GroupWise just starts and sits
there. The same happens with an OOo 2.0.2 built with the ooo-build patches (but
without win32-gw-send-mail.diff).

Or am I missing something and using the File:Send:Document as E-mail in the
wrong context? Should I already have started creating a message in the mail
client before invoking that menu item in Ooo? Or what?

setting target (2.0.3 is done already)
@tml: we can integrate any patch as soon as you have it working. Our new target
handling that reflects our train model is to use the "2.x" target that is
changed to the next milestone as soon as it becomes clear that the fix will make
it into it. 

About the problem: don't care for my crashes, as I wrote they where caused by
STL debug assertions that are only issued in a "non pro" build. I will create a
separete issue for this problem, most often these assertions are no important
problems ATM but they show buggy code that can create more serious ones in the
future.

About your problem with Groupwise: it's possibly a bug in GroupWise but also
possibly in the senddoc.cxx file. On a first glance I think that the OOo code
does not set the number of sent attachments at all, but maybe I overlooked
something. The current code at least works with all well known MAPI clients like
Mozilla, Thunderbird or Outlook Express.

First you should make sure that you send the correct content in lpszFileName so
that GroupWise can't be confused by it. Then we can examine the other paremeters
wether they are correct or if they work with TB etc. only "by luck".

It seems that this patch isn't needed with GroupWise 7.0.1 (2006-06-13), so
maybe we can just forget this whole issue. Michael?

sure - I know this was fixed in G/W - but it's still worth us committing the
workaround for older versions, people often take a long time to update -
particularly when the client costs money :-)

OK, well, this is fixed in CWS tml03, which has now been resynced to m185.

@tml: you didn't mention how you sorted your problems out. The patch is still
the same as in march but some problems are reported in may.

Re: the comment from Mon May 8 07:31:58 -0800 2006 : The nLastSlash variable was
a leftover that isn't needed. The current patch we have in ooo-build trunk looks
like this:

--- shell/source/win32/simplemail/senddoc.cxx	2005-02-08 11:09:48.562500000 +0530
+++ shell/source/win32/simplemail/senddoc.cxx	2005-02-09 13:59:06.140625000 +0530
@@ -64,7 +64,7 @@
 #endif
 
 #ifndef _RTL_STRING_HXX_
-//#include <rtl/string.hxx>
+#include <rtl/string.hxx>
 #endif
 
 #ifndef INCLUDED_SIMPLEMAPI_HXX
@@ -99,6 +99,7 @@
     StringList_t gCc;
     StringList_t gBcc;
     StringList_t gAttachments;
+	StringList_t gAttachFilenames;
     int gMapiFlags = 0;
 }
 
@@ -172,7 +173,11 @@
     {
         MapiFileDesc mfd;
         ZeroMemory(&mfd, sizeof(mfd));
+
         mfd.lpszPathName = const_cast<char*>(iter->c_str());    
+		rtl::OString aFullPath( mfd.lpszPathName );
+		gAttachFilenames.push_back( (const sal_Char *) aFullPath );
+		mfd.lpszFileName = const_cast<char*>(gAttachFilenames.back().c_str());    
         mfd.nPosition = sal::static_int_cast<ULONG>(-1);
         pMapiAttachmentList->push_back(mfd);        
     }            

You find me confused. :-)
If you have a CWS and it is "ready for QA" I would expect that you have a build
done with the latest patch that I can test. 

Do you have one?
Or should I take the patch and apply it to a CWS of my own to get it tested?

Hi *,

I'm currently working on a config with OOo 2.1 (Sun build)
and GourpWise client 7.0.1 (13-6-06)
on Suse Linux thin cliënts.
Mail from OOo doesn't work. Alas.
Could it be helpful if I give some (what?) more info about the configuration??
Thankx,

Cor

> Mail from OOo doesn't work. Alas.

In what way doesn't it work? Does OOo crash, does GroupWise crash, does nothing
happen at all, do you get some error message, or do you get to compose the
message in GroupWise and send it but it actually never arrives?

For me, on one machine with the Novell Edition of OOo 2.0.4 and the same version
of GroupWise client that you have, sending mail from OOo works. I get the
GroupWise mail composition dialog, with the document already attached. 

But on another machine, trying to send mail from OOo for some reason gives an
odd Outlook error message, even though I do have the same GroupWise client on
that machine, too. Weird.

The error message is:
"No working e-mail configuration was found..."

OK, that is the same message I saw on the other machine. Probably this is then
caused by some confusion between Outlook, GroupWise and Windows about what the
preferrd MUA on the machine should be. Try reinstalling GroupWise? (I don't know
if it goes through the same codepath at all, but what happens if you open a
mailto: link in your web browser?)

(Your problem presumably has nothing to do with OOo, at least not with the
original crasher problem this bug report is about, so we should continue this
discussion by email. tml@novell.com )

> so we should continue this discussion by email.

Thanks - fine offer.
If we find something of use for a wider audience, I'll come back here to report
that.

tml: I hate to annoy people but could you please answer my last question? I
still don't know ho to proceed. If you could attach the latest patch for your
problem to this issue and tell me that *this* patch is the one you want to get
integrated and that it fixes your problem I could proceed.

Until now we have an attached patch that obviously isn't the right one as you
reported remaining problems after the submission and we have some source code
pasted into a comment. 

Well, I am also confused about what to do with this. As mmeeks says in his
comment from Tue Sep 26 16:37:35 +0000 2006, the problem apparently has been
fixed in current GroupWise releases. So why bother adding workarounds to OOo for
obsolete other software?

But on the other hand, we probably will still keep the patch (as it is presented
in my comment from Jan 11 10:48:06 +0000 2007) in the ooo-build version, as it
already is there, doesn't apparently do any harm, just in case it happens to
help with some older GroupWise version, if somebody still runs such. I have no
idea how eagerly GroupWise-using sites keep their software up-to-date.