Subject: Attaching custom data to MAILSTREAM

From: Jeff Watkins <[email-masked]>
Date: Mon, 28 May 2001 12:03:19 -0700

I've only just started using the c-client library, so please forgive me 
if this issue has been solved many times before. I'd like to have 
several windows open, each browsing a different mailbox. But the 
c-client library doesn't allow me to define my own callbacks for a given 
stream. I had thought about adding an element to the MAILSTREAM 
structure that I could use like the following example:

void mm_exists( MAILSTREAM* Stream, unsigned long Number )
{
	if (Stream->my_ptr)
		((MyClass*)Stream->my_ptr)->mm_exists( Number );
}

and

MyClass::MyClass()
{
	stream= mail_open( NIL, "INBOX", NIL );
	if (stream)
		stream->my_ptr= this;
}

But this has a significant flaw: a callback may be made before returning 
from mail_open and so the my_ptr member hasn't been set yet.

Any suggestions?

Jeff

--
Jeff Watkins
[email-masked]
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 May 2001 12:03:33 -0700 (PDT)

On Mon, 28 May 2001 12:03:19 -0700, Jeff Watkins wrote:
> I'd like to have
> stream.

The standard way to do this is to have a global linked list matching
MAILSTREAM to window (or structure including window).  If the MAILSTREAM isn't
on the list, you can either instantiate one or return NIL and disregards it.

This is what I did with my NeXT MailManager application 12 years ago, and with
my MM-D application on Xerox Lisp machines before that.

Since you're only going to have a few windows open at any time, it's alright
to run down a linked list.  If you were doing something on a server, juggling
hundreds of MAILSTREAMs, then you might want a hash lookup.

---

From: Jeff Watkins <[email-masked]>
Date: Tue, 29 May 2001 14:41:04 -0700

> on the list, you can either instantiate one or return NIL and disregards 

The way I'm more familiar with is supplying a user data item to the create 
(or mail_open in this case) function. That way there is no lookup cost. 
The create function sets the user data member before any methods could 
possibly be called.

I looked into modifying the library to support this, but there seems to be 
eight million calls to mail_open for most of which I'm not certain I 
understand the context sufficiently.

I've implemented a lookup using an STL map (which is probably overkill for 
having two or three windows) but it works.

Jeff
--
Jeff Watkins
[email-masked]

---

From: Julian Hall <[email-masked]>
Date: Wed, 30 May 2001 10:08:01 +0100

I haven't done this with C-Client, but when writing a C++ class library for
Windows I encountered a similar problem (ie, I was storing a pointer to the
Window object using SetWindowLong/GetWindowLong, but couldn't do this until
after CreateWindow() returned by which time several callbacks had occurred
that I wasn't able to process).

I solved this by having a global variable which was a pointer to the object
that was currently being created, therefore if the pointer within the native
structure hadn't been set to non-NULL, I could just assume that the global
variable should be used instead.