SQLite + threads?

Why? If you want message history, save it to the database when you close the IM window. It doesn't *need* its own thread.

If you are talking about displaying the history, break it up into chunks to display. No need for a thread there either :)

Those are my suggestions

There's no need for a thread. SQLite performs well enough that you could get away with inserting each message when it is sent or received.

Glad to hear it.

Say a user lists all conversations they have ever engaged in...or searches on something vague and commonplace...like, "e". Lots of results will be returned. Wouldn't I need a thread for this? I don't want to starve the message loop here

Quote:

Original post by antareus Glad to hear it. Say a user lists all conversations they have ever engaged in...or searches on something vague and commonplace...like, "e". Lots of results will be returned. Wouldn't I need a thread for this? I don't want to starve the message loop here

Most programs will tell you that if you enter a term that is too broard - to narrrow the search some. You could implement a feature that gets the total results and if it is greater - than lets say 500 - to refine the search. That would be my idea for that.

Good to see you're still working on this, ant :)

Anyways, let's just say for the sake of education here that you were to use threads.

Probably the easiest way of going about something like this would be to create a separate thread, and have that other thread run it's own message loop.

Then, when you wanted to perform some database operation, all you gotta do is PostMessage() to that thread, using a custom message identifier, and then pass along some context information in WPARAM and LPARAM.

Should be fairly easy to do in WTL (which I assume you're still using, right?).