diff options
author | Alexey Kulakov <panda75@bk.ru> | 2012-07-04 20:10:29 +0000 |
---|---|---|
committer | Alexey Kulakov <panda75@bk.ru> | 2012-07-04 20:10:29 +0000 |
commit | 65e002b63efdb00571d0ba4ec1a73b14e1d7d3a0 (patch) | |
tree | d96b2f52ca3c89172f269cdb172c89cf6141d69c /include/delphi/m_protosvc.inc | |
parent | d7f143dba9e53347a1d7897bcd3989751c7f45f8 (diff) |
Pascal headers moved to include\delphi directory (with small updates)
removed deprecated m_mwclc.h file and link on it in AutoShutdown plugin
git-svn-id: http://svn.miranda-ng.org/main/trunk@763 1316c22d-e87f-b044-9b9b-93d7a3e3ba9c
Diffstat (limited to 'include/delphi/m_protosvc.inc')
-rw-r--r-- | include/delphi/m_protosvc.inc | 1639 |
1 files changed, 930 insertions, 709 deletions
diff --git a/include/delphi/m_protosvc.inc b/include/delphi/m_protosvc.inc index e546d5775b..2076dbc8bc 100644 --- a/include/delphi/m_protosvc.inc +++ b/include/delphi/m_protosvc.inc @@ -1,8 +1,7 @@ -(*
-
+{
Miranda IM: the free IM client for Microsoft* Windows*
-Copyright 2000-2003 Miranda ICQ/IM project,
+Copyright 2000-2009 Miranda ICQ/IM project,
all portions of this codebase are copyrighted to the people
listed in contributors.txt.
@@ -19,12 +18,30 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-
-*)
+}
{$IFNDEF M_PROTOSVC}
{$DEFINE M_PROTOSVC}
+{ ***** Unicode Services note ********
+******************************************
+
+Only new style protocols (Miranda 0.9+) with m_iVersion set to 2 or higher
+support Unicode services documented below, all other support only ANSI.
+
+For all other that do not support Unicode services, Miranda core will
+convert Unicode to ANSI and call the appropriate service.
+}
+
+type
+// PFNAMECHAR = ^FNAMECHAR;
+//#if MIRANDA_VER >= 0x0900
+ FNAMECHAR = TCHAR;
+//#else
+// FNAMECHAR = AnsiChar;
+//#endif
+ TFNAMECHAR = FNAMECHAR;
+
{<</
none of these services should be used on there own (i.e. using CallService(), etc)
hence the PS_ prefix, instead use the services exposed in m_protocols.inc
@@ -45,716 +62,920 @@ Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. />>}
const
+ PFLAGNUM_1 = $1;
+ PF1_IMSEND = $00000001; // supports IM sending
+ PF1_IMRECV = $00000002; // supports IM receiving
+ PF1_IM = (PF1_IMSEND or PF1_IMRECV);
+ PF1_URLSEND = $00000004; // supports separate URL sending
+ PF1_URLRECV = $00000008; // supports separate URL receiving
+ PF1_URL = (PF1_URLSEND or PF1_URLRECV);
+ PF1_FILESEND = $00000010; // supports file sending
+ PF1_FILERECV = $00000020; // supports file receiving
+ PF1_FILE = (PF1_FILESEND or PF1_FILERECV);
+ PF1_MODEMSGSEND = $00000040; // supports broadcasting away messages
+ PF1_MODEMSGRECV = $00000080; // supports reading others' away messages
+ PF1_MODEMSG = (PF1_MODEMSGSEND or PF1_MODEMSGRECV);
+ PF1_SERVERCLIST = $00000100; // contact lists are stored on the server, not locally. See notes below
+ PF1_AUTHREQ = $00000200; // will get authorisation requests for some or all contacts
+ PF1_ADDED = $00000400; // will get 'you were added' notifications
+ PF1_VISLIST = $00000800; // has an invisible list
+ PF1_INVISLIST = $00001000; // has a visible list for when in invisible mode
+ PF1_INDIVSTATUS = $00002000; // supports setting different status modes to each contact
+ PF1_EXTENSIBLE = $00004000; // the protocol is extensible and supports plugin-defined messages
+ PF1_PEER2PEER = $00008000; // supports direct (not server mediated) communication between clients
+ PF1_NEWUSER = $00010000; // supports creation of new user IDs
+ PF1_CHAT = $00020000; // has a realtime chat capability
+ PF1_INDIVMODEMSG = $00040000; // supports replying to a mode message request with different text depending on the contact requesting
+ PF1_BASICSEARCH = $00080000; // supports a basic user searching facility
+ PF1_EXTSEARCH = $00100000; // supports one or more protocol-specific extended search schemes
+ PF1_CANRENAMEFILE = $00200000; // supports renaming of incoming files as they are transferred
+ PF1_FILERESUME = $00400000; // can resume broken file transfers, see PS_FILERESUME below
+ PF1_ADDSEARCHRES = $00800000; // can add search results to the contact list
+ PF1_CONTACTSEND = $01000000; // can send contacts to other users
+ PF1_CONTACTRECV = $02000000; // can receive contacts from other users
+ PF1_CONTACT = (PF1_CONTACTSEND or PF1_CONTACTRECV);
+ PF1_CHANGEINFO = $04000000; // can change our user information stored on server
+ PF1_SEARCHBYEMAIL = $08000000; // supports a search by e-mail feature
+ PF1_USERIDISEMAIL = $10000000; // set if the uniquely identifying field of the network is the e-mail address
+ PF1_SEARCHBYNAME = $20000000; // supports searching by nick/first/last names
+ PF1_EXTSEARCHUI = $40000000; // has a dialog box to allow searching all the possible fields
+ PF1_NUMERICUSERID = $80000000; // the unique user IDs for this protocol are numeric
+
+ PFLAGNUM_2 = 2; // the status modes that the protocol supports
+ PF2_ONLINE = $00000001; // an unadorned online mode
+ PF2_INVISIBLE = $00000002;
+ PF2_SHORTAWAY = $00000004; // Away on ICQ, BRB on MSN
+ PF2_LONGAWAY = $00000008; // NA on ICQ, Away on MSN
+ PF2_LIGHTDND = $00000010; // Occupied on ICQ, Busy on MSN
+ PF2_HEAVYDND = $00000020; // DND on ICQ
+ PF2_FREECHAT = $00000040;
+ PF2_OUTTOLUNCH = $00000080;
+ PF2_ONTHEPHONE = $00000100;
+ PF2_IDLE = $00000200; //added during 0.3.4 (2004/09/13)
+
+ PFLAGNUM_3 = 3; //the status modes that the protocol supports
+ //away-style messages for. Uses the PF2_ flags.
+
+ PFLAGNUM_4 = 4; // v0.3+: flag asking a protocol plugin how auths are handled
+ PF4_FORCEAUTH = $00000001; // protocol has to send auth's for things to work
+ PF4_FORCEADDED = $00000002; // protocol has to tell people that they were added (otherwise things don't work)
+ PF4_NOCUSTOMAUTH = $00000004; // protocol can't send a custom message while asking others for auth
+ PF4_SUPPORTTYPING = $00000008; // protocol supports user is typing messages v0.3.3+
+ PF4_SUPPORTIDLE = $00000010; // protocol understands idle, added during v0.3.4+ (2004/09/13)
+ PF4_AVATARS = $00000020; // protocol has avatar support, added during v0.3.4 (2004/09/13)
+ PF4_OFFLINEFILES = $00000040; // protocols supports sending files to offline users (v0.5.2)
+ PF4_IMSENDUTF = $00000080; // protocol is able to process messages in utf-8 (v.0.7.0+)
+ PF4_IMSENDOFFLINE = $00000100; // protocol supports sending offline messages (v0.8.0+)
+ PF4_INFOSETTINGSVC = $00000200; // protocol supports user info translation services (v0.8.0+)
+ PF4_NOAUTHDENYREASON = $00000400; // protocol doesn't support authorization deny reason (v0.9.0+)
+
+ PFLAG_UNIQUEIDTEXT = 100; // returns a static buffer of text describing the unique field by which this protocol identifies users (already translated), or NULL
+ PFLAG_MAXCONTACTSPERPACKET = 200; // v0.1.2.2+: returns the maximum number of contacts which can be sent in a single PSS_CONTACTS. lParam=(LPARAM)hContact.
+ PFLAG_UNIQUEIDSETTING = 300; // v0.3+: returns the DB setting name (e.g. szProto=ICQ, szSetting=UIN) that has the ID which makes this user unique on that system (0.3a ONLY), the string is statically allocated so no need to free()
+ PFLAG_MAXLENOFMESSAGE = 400; // v0.3.2+: return the maximum length of an instant message, lParam=(LPARAM)hContact
+ {
+ A protocol might not support this cap, it allows a protocol to say that PFLAGNUM_2 is for
+ statuses contacts supports, and that PFLAGNUM_5 is for statuses a protocol can SET TO ITSELF,
+ if this is not replied to, then PFLAGNUM_2 is alone in telling you which statuses a protocol
+ can set to and what statuses a contact can set to as well.
+
+ E.g. A protocol might report 'wireless' users but a login of the protocol from Miranda can
+ not set itself to 'wireless' so PFLAGNUM_2 would return PF2_ONTHEPHONE and PFLAGNUM_5 would
+ return PF2_ONTHEPHONE as well, this means "I will get contacts who are on the phone but you can
+ not set on the phone" and so on.
+
+ Do note that the reply here is a NEGATION of bitflags reported for PFLAGNUM_2, e.g. returning
+ PF2_ONTHEPHONE for PFLAGNUM_2 and returning the same for PFLAGNUM_5 says that you DO NOT SUPPORT
+ PF2_ONTHEPHONE for the user to PS_SETSTATUS to, but you will expect other contacts to have
+ that status, e.g. you can get onthephone for users but can't go online with onthephone.
+
+ The same PF2_ status flags are used in the reply.
+
+ Added during 0.3.4 (2004/09/14)
+ }
+
+ PFLAGNUM_5 = 5;
+
+ // for PS_SETSTATUS
+
+ LOGINERR_WRONGPASSWORD = 1;
+ LOGINERR_NONETWORK = 2;
+ LOGINERR_PROXYFAILURE = 3;
+ LOGINERR_BADUSERID = 4;
+ LOGINERR_NOSERVER = 5;
+ LOGINERR_TIMEOUT = 6;
+ LOGINERR_WRONGPROTOCOL = 7;
+ LOGINERR_OTHERLOCATION = 8;
+
+ // flag for PS_ADDTOLIST
+
+ PALF_TEMPORARY = 1; // add the contact temporarily and invisibly, just to get user info or something
+
+ // flags for PS_GETINFO
+
+ SGIF_MINIMAL = 1; // get only the most basic information. This should
+ // contain at least a Nick and e-mail.
+ SGIF_ONOPEN = 2; // set when the User Info form is being opened
+
+ // for PSR_MESSAGE
+
+ PREF_CREATEREAD = 1; // create the database event with the 'read' flag set
+ PREF_UNICODE = 2;
+ PREF_RTL = 4; // 0.5+ addition: support for right-to-left messages
+ PREF_UTF = 8; // message is in utf-8 (0.7.0+)
+
+ // for PS_FILERESUME
+
+ FILERESUME_OVERWRITE = 1;
+ FILERESUME_RESUME = 2;
+ FILERESUME_RENAME = 3;
+ FILERESUME_SKIP = 4;
- PFLAGNUM_1 = $1;
- PF1_IMSEND = $00000001; // supports IM sending
- PF1_IMRECV = $00000002; // supports IM receiving
- PF1_IM = (PF1_IMSEND or PF1_IMRECV);
- PF1_URLSEND = $00000004; // supports separate URL sending
- PF1_URLRECV = $00000008; // supports separate URL receiving
- PF1_URL = (PF1_URLSEND or PF1_URLRECV);
- PF1_FILESEND = $00000010; // supports file sending
- PF1_FILERECV = $00000020; // supports file receiving
- PF1_FILE = (PF1_FILESEND or PF1_FILERECV);
- PF1_MODEMSGSEND = $00000040; // supports broadcasting away messages
- PF1_MODEMSGRECV = $00000080; // supports reading others' away messages
- PF1_MODEMSG = (PF1_MODEMSGSEND or PF1_MODEMSGRECV);
- PF1_SERVERCLIST = $00000100; // contact lists are stored on the server, not locally. See notes below
- PF1_AUTHREQ = $00000200; // will get authorisation requests for some or all contacts
- PF1_ADDED = $00000400; // will get 'you were added' notifications
- PF1_VISLIST = $00000800; // has an invisible list
- PF1_INVISLIST = $00001000; // has a visible list for when in invisible mode
- PF1_INDIVSTATUS = $00002000; // supports setting different status modes to each contact
- PF1_EXTENSIBLE = $00004000; // the protocol is extensible and supports plugin-defined messages
- PF1_PEER2PEER = $00008000; // supports direct (not server mediated) communication between clients
- PF1_NEWUSER = $00010000; // supports creation of new user IDs
- PF1_CHAT = $00020000; // has a realtime chat capability
- PF1_INDIVMODEMSG = $00040000; // supports replying to a mode message request with different text depending on the contact requesting
- PF1_BASICSEARCH = $00080000; // supports a basic user searching facility
- PF1_EXTSEARCH = $00100000; // supports one or more protocol-specific extended search schemes
- PF1_CANRENAMEFILE = $00200000; // supports renaming of incoming files as they are transferred
- PF1_FILERESUME = $00400000; // can resume broken file transfers, see PS_FILERESUME below
- PF1_ADDSEARCHRES = $00800000; // can add search results to the contact list
- PF1_CONTACTSEND = $01000000; // can send contacts to other users
- PF1_CONTACTRECV = $02000000; // can receive contacts from other users
- PF1_CONTACT = (PF1_CONTACTSEND or PF1_CONTACTRECV);
- PF1_CHANGEINFO = $04000000; // can change our user information stored on server
- PF1_SEARCHBYEMAIL = $08000000; // supports a search by e-mail feature
- PF1_USERIDISEMAIL = $10000000; // set if the uniquely identifying field of the network is the e-mail address
- PF1_SEARCHBYNAME = $20000000; // supports searching by nick/first/last names
- PF1_EXTSEARCHUI = $40000000; // has a dialog box to allow searching all the possible fields
- PF1_NUMERICUSERID = $80000000; // the unique user IDs for this protocol are numeric
-
- PFLAGNUM_2 = 2; // the status modes that the protocol supports
- PF2_ONLINE = $00000001; // an unadorned online mode
- PF2_INVISIBLE = $00000002;
- PF2_SHORTAWAY = $00000004; // Away on ICQ, BRB on MSN
- PF2_LONGAWAY = $00000008; // NA on ICQ, Away on MSN
- PF2_LIGHTDND = $00000010; // Occupied on ICQ, Busy on MSN
- PF2_HEAVYDND = $00000020; // DND on ICQ
- PF2_FREECHAT = $00000040;
- PF2_OUTTOLUNCH = $00000080;
- PF2_ONTHEPHONE = $00000100;
-
- PFLAGNUM_3 = 3; //the status modes that the protocol supports
- //away-style messages for. Uses the PF2_ flags.
- PFLAG_UNIQUEIDTEXT = 100; //returns a static buffer of text describing the unique field by which this protocol identifies users (already translated), or NULL
-
- PFLAG_MAXCONTACTSPERPACKET = 200; //v0.1.2.2+: returns the maximum number of contacts which can be sent in a single PSS_CONTACTS.
-
- PFLAGNUM_4 = 4; // v0.3+: flag asking a protocol plugin how auths are handled
- PF4_FORCEAUTH = $00000001; // protocol has to send auth's for things to work
- PF4_FORCEADDED = $00000002; // protocol has to tell people that they were added (otherwise things don't work)
- PF4_NOCUSTOMAUTH = $00000004; // protocol can't send a custom message while asking others for auth
- PF4_SUPPORTTYPING = $00000008; // protocol supports user is typing messages v0.3.3+
- PF4_SUPPORTIDLE = $00000010; // protocol understands idle, added during v0.3.4+ (2004/09/13)
- PF4_AVATARS = $00000020; // protocol has avatar support, added during v0.3.4 (2004/09/13)
- PF4_OFFLINEFILES = $00000040; // protocols supports sending files to offline users (v0.5.2)
- PF4_IMSENDUTF = $00000080; // protocol is able to process messages in utf-8 (v.0.7.0+)
- PF4_IMSENDOFFLINE = $00000100; // protocol supports sending offline messages (v0.8.0+)
- PF4_INFOSETTINGSVC = $00000200; // protocol supports user info translation services (v0.8.0+)
-
- PFLAG_UNIQUEIDSETTING = 300; // v0.3+: returns the DB setting name (e.g. szProto=ICQ, szSetting=UIN) that has the ID which makes this user unique on that system (0.3a ONLY), the string is statically allocated so no need to free()
-
- // for PS_SETSTATUS
-
- LOGINERR_WRONGPASSWORD = 1;
- LOGINERR_NONETWORK = 2;
- LOGINERR_PROXYFAILURE = 3;
- LOGINERR_BADUSERID = 4;
- LOGINERR_NOSERVER = 5;
- LOGINERR_TIMEOUT = 6;
- LOGINERR_WRONGPROTOCOL = 7;
-
- // flag for PS_ADDTOLIST
-
- PALF_TEMPORARY = 1; // add the contact temporarily and invisibly, just to get user info or something
-
- // flags for PS_GETINFO
-
- SGIF_MINIMAL = 1; // get only the most basic information. This should
- // contain at least a Nick and e-mail.
-
- // for PSR_MESSAGE
-
- PREF_CREATEREAD = 1; // create the database event with the 'read' flag set
-
- // for PS_FILERESUME
-
- FILERESUME_OVERWRITE= 1;
- FILERESUME_RESUME = 2;
- FILERESUME_RENAME = 3;
- FILERESUME_SKIP = 4;
+const
+ PSR_UNICODE = 1;
type
+ PPROTOSEARCHRESULT = ^TPROTOSEARCHRESULT;
+ TPROTOSEARCHRESULT = record
+ cbSize : int;
+ nick : TFNAMECHAR;
+ firstName: TFNAMECHAR;
+ lastName : TFNAMECHAR;
+ email : TFNAMECHAR;
+ id : TFNAMECHAR;
+ flags : int;
+ reserved : array [0..(8*SizeOf(THANDLE) div SizeOf(dword))-1] of Byte;
+ // Protocols may extend this structure with extra members at will and supply
+ // a larger cbSize to reflect the new information, but they must not change
+ // any elements above this comment
+ // The 'reserved' field is part of the basic structure, not space to
+ // overwrite with protocol-specific information.
+ // If modules do this, they should take steps to ensure that information
+ // they put there will be retained by anyone trying to save this structure.
+ end;
+
+ PPROTOSEARCHBYNAME = ^TPROTOSEARCHBYNAME;
+ TPROTOSEARCHBYNAME = record
+ pszNick : TChar;
+ pszFirstName: TChar;
+ pszLastName : TChar;
+ end;
+
+ PPROTORECVEVENT = ^TPROTORECVEVENT;
+ TPROTORECVEVENT = record
+ flags : DWORD;
+ timestamp: DWORD;
+ szMessage: TChar;
+ lParam : LPARAM;
+ end;
+
+ PPROTORECVFILE = ^TPROTORECVFILE;
+ TPROTORECVFILE = record
+ flags : DWORD;
+ timestamp : DWORD; // unix time
+ szDescription: PAnsiChar;
+ pFiles : ^PAnsiChar; // pointer to an array of PAnsiChar's
+ lParam : LPARAM;
+ end;
+
+ //File(s) have been received (0.9.x)
+ PPROTORECVFILET = ^TPROTORECVFILET;
+ TPROTORECVFILET = record
+ flags : DWORD;
+ timestamp : DWORD; // unix time
+ szDescription: TChar;
+ FileCount : int;
+ pFiles : ^TChar; // pointer to an array of PAnsiChar's
+ lParam : LPARAM;
+ end;
+
+ PPROTOFILERESUME = ^TPROTOFILERESUME;
+ TPROTOFILERESUME = record
+ action : int; // FILERESUME_* flag
+ szFilename: TFNAMECHAR; // full path, only valid if action=FILERESUME_RENAME
+ end;
- PPROTOSEARCHRESULT = ^TPROTOSEARCHRESULT;
- TPROTOSEARCHRESULT = record
- cbSize: int;
- nick: PChar;
- firstName: PChar;
- lastName: PChar;
- email: PChar;
- reserved: array [0..15] of Byte;
- // Protocols may extend this structure with extra members at will and supply
- // a larger cbSize to reflect the new information, but they must not change
- // any elements above this comment
- // The 'reserved' field is part of the basic structure, not space to
- // overwrite with protocol-specific information.
- // If modules do this, they should take steps to ensure that information
- // they put there will be retained by anyone trying to save this structure.
- end;
-
- PPROTOSEARCHBYNAME = ^TPROTOSEARCHBYNAME;
- TPROTOSEARCHBYNAME = record
- pszNick: PChar;
- pszFirstName: PChar;
- pszLastName: PChar;
- end;
-
- PPROTORECVEVENT = ^TPROTORECVEVENT;
- TPROTORECVEVENT = record
- flags: DWORD;
- timestamp: DWORD;
- szMessage: PChar;
- lParam: LPARAM;
- end;
-
- PPROTORECVFILE = ^TPROTORECVFILE;
- TPROTORECVFILE = record
- flags: DWORD;
- timestamp: DWORD; // unix time
- szDescription: PChar;
- pFiles: PChar; // pointer to an array of pchar's
- lParam: LPARAM;
- end;
-
- PPROTOFILERESUME = ^TPROTOFILERESUME;
- TPROTOFILERESUME = record
- action: int; // FILERESUME_* flag
- szFilename: PChar; // full path, only valid if action=FILERESUME_RENAME
- end;
+const
+ {
+ wParam : PFLAGNUM_* (see above)
+ lParam : 0
+ Affects: Returns a bitfield for settings corresponding to flag number, see notes
+ Returns: a bitfield of supported features -- or 0 if flag_num is not supported
+ Notes : this checks what sort of things are actively supported by a protocol
+ module
+ }
+ PS_GETCAPS = '/GetCaps';
+
+ {
+ wParam : cchName
+ lParam : Pointer to a buffer to fill with human-readable name
+ Affect : Get a human-readable name for the protocol, see notes
+ Result : 0 on success, [non zero] on failure
+ Notes : Should be translated before being returned, cchName
+ has the size of the buffer, example strings: "ICQ", "AIM"
+ }
+ PS_GETNAME = '/GetName';
+
+ {
+ wParam : whichIcon
+ lParam : 0
+ Affect : Loads one of the protocol-sspecific icons
+ Returns: the HICON or NULL on failure, the returned icon
+ must be DestroyIcon()ed, the UI should overlay
+ the online icon with further UI-specified icon to
+ repressent the exact status mode.
+ }
+ PLI_PROTOCOL = $1; // An icon representing the protocol (eg the multicoloured flower for ICQ)
+ PLI_ONLINE = $2; // Online state icon for that protocol (eg green flower for ICQ)
+ PLI_OFFLINE = $3; // Offline state icon for that protocol (eg red flower for ICQ)
+
+ PLIF_LARGE = $0; // Or with one of the above to get the large (32x32 by default) icon
+ PLIF_SMALL = $10000; // Or with one of the above to get the small (16x16 by default) icon
+ PLIF_ICOLIB = $20000; // the returned HICON is managed by IcoLib, DO NOT DestroyIcon() it
+ PLIF_ICOLIBHANDLE = $40000; // the function will return IcoLib handle not HICON
+
+ PS_LOADICON = '/LoadIcon';
+
+ {
+ wParam : status_mode
+ lParam : Pointer to a null terminated string containing message
+ Affect : Sets the status mode specific message for the user, see notes
+ Returns: 0 on success, [non zero] on failure
+ Notes : This service is not available unless PF1_MODEMSGSEND is set,
+ and PF1_INDIVMODEMSG is *not* set.
+ If PF1_INDIVMODEMSG is set, then see PSS_AWAYMSSG for details
+ of operations of away messages.
+ -
+ Protocol modules smust support lParam=NULL, it may eithere mean
+ to use an empty message or (preferably) not to reply at all to
+ any requests.
+ }
+ PS_SETAWAYMSG = '/SetAwayMsg';
+ PS_SETAWAYMSGW = '/SetAwayMsgW';
+
+ {
+ wParam : newMode from statusmodes.inc
+ lParam : 0
+ Affect : Change the protocol's status mode, see notes
+ Returns: 0 on success, [non zero] on failure
+ Notes : Will send an ack with :
+ type=ACKTYPE_SUCCESS, result=ACKRESULT_SUCCESS, hProcess=previousMode, lParam=newMode
+ -
+ when the change completes. This ack is sent for all changes, not
+ just ones caused by calling this function.
+ -
+ NewMode can be ID_STATUS_CONNECTING<=newMode<ID_STATUS_CONNECTING+
+ MAX_CONNECT_RETRIES to signify that it's connecting and it's the nth retry.
+ -
+ Protocols are initially always in offline mode, if a protocol
+ doesn't support a specific status mode, it should pick the closest
+ ones that it does support, and change to that.
+
+ If a protocol has to switch from offline mode to online (or a substate
+ of online, like away) then it should report any errors in the
+ form of an additional ack :
+
+ type=ACKTYPE_LOGIN, result=ACKRESULT_FAILURE, hProcess=NULL, lParam=LOGINERR_*
+
+ SetStatus() is called when a protocol module is first loaded
+ with newMode=ID_STATUS_ONLINE.
+ -
+ Protocols can define their own LOGINERR_* starting at $1000, see
+ LOGINERR_* above
+ }
+ PS_SETSTATUS = '/SetStatus';
+
+ {
+ wParam : 0
+ lParam : 0
+ Affect : Get the status mode that a protocol is currently in, see notes
+ Returns: The current status mode
+ Notes : Only protocol modules need to implement this, non network level
+ protocol modules do not need to (but if you register as a protocol
+ you need to, Miranda will GPF otherwise)
+ }
+ PS_GETSTATUS = '/GetStatus';
+
+ {
+ wParam : HDBEVENT
+ lParam : 0
+ Affect : allow 'somebody' to add the user to their contact list, see notes
+ Returns: 0 on success, [non zero] on failure
+ Notes : Auth request come in the form of an event added to the database
+ for the NULL(0) user, the form is:
+ -
+ protocolSpecific: DWORD;
+ nick, firstname, lastName, e-mail, requestReason: ASCIIZ;
+ -
+ HDBEVENT musts be the handle of such an event, one or more
+ fields may be empty if the protocol doesn't support them
+ }
+ PS_AUTHALLOW = '/Authorize';
+
+ {
+ wParam : HDBEVENT
+ lParam : TChar - Reason
+ Affect : Deny an authorisation request
+ Returns: 0 on success, [non zero] on failure
+ Notes : Protocol modules must be able to cope with lParam=NULL(0)
+ }
+ PS_AUTHDENY = '/AuthDeny';
+ PS_AUTHDENYW = '/AuthDenyW';
+
+ {
+ Send a "You were added" event
+ wParam=lParam=0
+ Returns 0 on success, nonzero on failure
+ }
+ PSS_ADDED = '/YouWereAdded';
+
+{ Create account manager UI form
+ wParam=0
+ lParam=(LPARAM)(HWND)hwndAccMgr
+ Returns handle on newly created form.
+ Size for best fit is 186x134 DLUs, please avoid groupboxes
+ paddind and advanced options. This should provide minimal setup
+ for initial connect.
+}
+ PS_CREATEACCMGRUI = '/CreateAccMgrUI';
+ {
+ wParam : 0
+ lParam : Pointer to a null terminated string containing an ID to search for
+ Affect : Send a basic search request, see notes
+ Returns: A handle to the search request or NULL(0) on failure
+ Notes : All protocols identify users uniquely by a single field
+ this service will search by that field.
+ -
+ All search replies (even protocol-spec extended searches)
+ are replied by a series of ack's,-
+ -
+ Result acks are a series of:
+ type=ACKTYPE_SEARCH, result=ACKRESULT_DATA, lParam=Pointer to a TPROTOSEARCHRESULT structure
+ -
+ ending ack:
+ type=ACKTYPE_SEARCH, result=ACKRESULT_SUCCESS, lParam=0
+ -
+ The pointers in the structure are not guaranteed to be
+ valid after the ack is complete.
+ -
+ The structure to reply with search results can be extended
+ per protocol basis (see below)
+
+ }
+ PS_BASICSEARCH = '/BasicSearch';
+ PS_BASICSEARCHW = '/BasicSearchW';
+
+ {
+ wParam : 0
+ lParam : Pointer to a NULL terminated string containing the e-mail to search for
+ Affect : Search for user(s) by e-mail address, see notes
+ Returns: A HANDLE to the search, or NULL(0) on failure
+ Notes : Results are returned as for PS_BASICSEARCH, this service
+ is only available if the PF1_USERIDISEMAIL flag is set for caps --
+ -
+ This service with the above service should be mapped to the same
+ function if the aforementioned flag is set.
+ Version: v0.1.2.1+
+ }
+ PS_SEARCHBYEMAIL = '/SearchByEmail';
+ PS_SEARCHBYEMAILW = '/SearchByEmailW';
+
+ {
+ wParam : 0
+ lParam : Pointer to a TPROTOSEARCHBYNAME structure
+ Affect : Search for users by name, see notes
+ Returns: Handle to the search, NULL(0) on failure
+ Notes : this service is only available, if PF1_SEARCHBYNAME capability is set.
+ Results are returned in the same manner as PS_BASICSEEARCH
+ Version: v0.1.2.1+
+ }
+ PS_SEARCHBYNAME = '/SearchByName';
+ PS_SEARCHBYNAMEW = '/SearchByNameW';
+
+ {
+ wParam : 0
+ lParam : Handle to window owner
+ Affect : Create the advanced search dialog box, see notes
+ Returns: A window handle, or NULL(0) on failure
+ Notes : this service is only available if PF1_EXTSEARCHUI capability is
+ set, advanced search is very protocol-spec'd so it is left to
+ the protocol itself to supply a dialog containing the options,
+ this dialog should not have a titlebar and contain only search
+ fields. the rest of the UI is supplied by Miranda.
+ -
+ The dialog should be created with CreateDialog() or it's kin
+ and still be hidden when this function returns,
+ -
+ The dialog will be destroyed when the find/add dialog is closed
+ Version: v0.1.2.1+
+ }
+ PS_CREATEADVSEARCHUI = '/CreateAdvSearchUI';
+
+ {
+ wParam : 0
+ lParam : Handle to advanced search window handle
+ Affect : Search using the advanced search dialog, see notes
+ Returns: A handle or NULL(0) on failure
+ Notes : Results are returned in the same manner as PS_BASICSEARCH,
+ this service is only available if PF1_EXTSEARCHUI capability is set
+ Version: v0.1.2.1+
+ }
+ PS_SEARCHBYADVANCED = '/SearchByAdvanced';
+type
+ CUSTOMSEARCHRESULTS = record
+ nSize :size_t;
+ nFieldCount:int;
+ szFields :^TCHAR;
+ psr :TPROTOSEARCHRESULT;
+ end;
+
+ {
+ wParam : flags
+ lParam : Pointer to a TPROTOSEARCHRESULT structure
+ Affect : Adds a search result to the contact list, see notes
+ Returns: A handle to the new contact (HCONTACT) or NULL(0) on failure
+ Notes : The pointer MUST be a result returned by a search function
+ since there maybe extra protocol-spec data required by the protocol.
+ -
+ the protocol module should not allow duplicate contains to be added,
+ but if such a request *is* received it should return a HCONTACT
+ to the original user,
+ -
+ If flags is PALF_TEMPORARY set, the contact should be added
+ temorarily and invisiblely, just to get the user info (??)
+ -
+ }
const
+ PS_ADDTOLIST = '/AddToList';
+
+ {
+ wParam : MAKEWPARAM(flags, iContact)
+ lParam : HDBEVENT
+ Affects: Add a contact to the contact list given an auth/added/contacts events, see notes
+ Returns: A HCONTACT or NULL(0) on failure
+ Notes : HDBEVENT must be either EVENTTYPE_AUTHREQ or EVENTTYPE_ADDED
+ flags are the same as PS_ADDTOLIST,
+ -
+ iContacts is only used for contacts vents, it is 0-based index
+ of the contacts in the event to add, there's no way to add two or more
+ contacts at once, you should just call this as many times as needed.
+ }
+ PS_ADDTOLISTBYEVENT = '/AddToListByEvent';
+
+ {
+ wParam : InfoType
+ lParam : Pointer to InfoData
+ Affect : Changes user details as stored on the server, see notes
+ Returns: A Handle to the change request or NULL(0) on failure
+ Notes : the details stored on the server are very protocol spec'd
+ so this service just supplies an outline for protocols to use.
+ See protocol-specific documentation for what infoTypes are available
+ and what InfoData should be for each infoTypes.
+ -
+ Sends an ack type=ACKTYPE_SETINFO, result=ACKRESULT_SUCCESS/FAILURE, lParam=0
+ -
+ This description just leaves me cold.
+ Version: v0.1.2.0+
+ }
+ PS_CHANGEINFO = '/ChangeInfo';
+
+ {
+ wParam : HFILETRANSFER
+ lParam : Pointer to a initalised TPROTOFILERESUME
+ Affect : Informs the protocol of the user's chosen resume behaviour, see notes
+ Returns: 0 on success, [non zero] on failure
+ Notes : If the protocol supports file resume (caps: PF1_FILERESUME) then before
+ each file receive begins it will broadcast an ack with :
+
+ type=ACKTYPE_FILE, result=ACKRESULT_RESUME, hProcess=hFileTransfer,
+ lParam = TPROTOFILETRANSFERSTATUS.
+
+ If the UI processes this ack it must return a [non zero] valuee from it's
+ hook, it all the hooks complete without returning [non zero] then the
+ protocol will assume that no resume UI was available and will continue
+ to receive the file with a default behaviour (default: overwrite)
+ -
+ If a hook does return [non zero] then that UI MUST call this service,
+ PS_FILERESUME at some point.
+ When the protocol module receives this call it will proceed wit the
+ file recieve usingg the given information.
+ -
+ Having sasid that, PS_FILERESUME MUST be called, it is also
+ acceptable to completely abort the transfer instead, i.e. the file
+ exists locally and the user doesn't want to overwrite or resume or
+ reget.
+ Version: v0.1.2.2+
+ }
+ PS_FILERESUME = '/FileResume';
+ PS_FILERESUMEW = '/FileResumeW';
+
+{
+ Asks a protocol to join the chatroom from contact v0.8.0+
+ wParam=(WPARAM)(HANDLE)hContact
+ lParam=(LPARAM)0
+ Returns 0 on success, nonzero on failure
+}
+ PS_JOINCHAT = '/JoinChat';
+
+{
+ Asks a protocol to leave the chatroom from contact v0.8.0+
+ wParam=(WPARAM)(HANDLE)hContact
+ lParam=(LPARAM)0
+ Returns 0 on success, nonzero on failure
+}
+ PS_LEAVECHAT = '/LeaveChat';
+
+{
+ Asks a protocol to read contact information and translate them (for a lookup fields) v0.8.0+
+ wParam=(WPARAM)(HANDLE)hContact
+ lParam=(LPARAM)(DBCONTACTGETSETTING*)&dbcgs
+ The flag PF4_INFOSETTINGSVC indicates that a protocol supports this. Basically it should
+ do the same as MS_DB_CONTACT_GETSETTING_STR, except that for a lookup settings (e.g. Language)
+ it returns string instead of an ID stored in the database.
+ Caller is responsible for free()ing dbcgs.pValue->pszVal and pbVal if they are
+ returned. You must **NOT** do this from your version of free() you have to use Miranda's free()
+ you can get a function pointer to Miranda's free() via MS_SYSTEM_GET_MMI, see m_system.h
+ Returns 0 on success or nonzero if the setting name was not found or hContact
+ was invalid
+}
+ PS_GETINFOSETTING = '/GetInfoSetting';
+
+{
+ Asks protocol for the status message for a status
+ wParam=(WORD) 0 for current status or a status id
+ lParam=SGMA_xxx
+ Returns status msg or NULL if there is none. The protocol have to handle only the current
+ status. Handling messages for other statuses is optional.
+ Remember to mir_free the return value
+}
+ SGMA_UNICODE = 1; // return Unicode status
+
+ PS_GETMYAWAYMSG = '/GetMyAwayMsg';
+
+{
+ Set nickname for the user
+ wParam=(WPARAM)SMNN_xxx
+ lParam=(LPARAM)(char *) The new nickname for the user
+ return=0 for success
+}
+ SMNN_UNICODE = 1; // return Unicode status
+
+ PS_SETMYNICKNAME = '/SetNickname';
+
+{
+ Get the max allowed length for the user nickname
+ Optional, default value is 1024
+ wParam=(WPARAM)0
+ lParam=(LPARAM)0
+ return= <=0 for error, >0 the max length of the nick
+}
+ PS_GETMYNICKNAMEMAXLENGTH = '/GetMyNicknameMaxLength';
+
+// WAYD = What are you doing
+ WAYD_UNICODE = 1; // return Unicode texts
+
+{
+ Get the WAYD message for the user
+ wParam=(WPARAM)WAYD_xxx
+ lParam=(LPARAM)0
+ Returns the text or NULL if there is none. Remember to mir_free the return value.
+}
+ PS_GETMYWAYD = '/GetMyWAYD';
+
+{
+ Sets the WAYD message for the user
+ wParam=(WPARAM)WAYD_xxx
+ lParam=(LPARAM)(WCHAR * or char *)The message
+ Returns 0 on success, nonzero on failure
+}
+ PS_SETMYWAYD = '/SetMyWAYD';
+
+{
+ Get the max allowed length that a WAYD message can have
+ Optional, default value is 1024
+ wParam=(WPARAM)0
+ lParam=(LPARAM)0
+ Returns the max length
+}
+ PS_GETMYWAYDMAXLENGTH = '/GetMyWAYDMaxLength';
+
+// these should be called with CallContactService()
- {
- wParam : PFLAGNUM_* (see above)
- lParam : 0
- Affects: Returns a bitfield for settings corresponding to flag number, see notes
- Returns: a bitfield of supported features -- or 0 if flag_num is not supported
- Notes : this checks what sort of things are actively supported by a protocol
- module
- }
- PS_GETCAPS = '/GetCaps';
-
- {
- wParam : cchName
- lParam : Pointer to a buffer to fill with human-readable name
- Affect : Get a human-readable name for the protocol, see notes
- Result : 0 on success, [non zero] on failure
- Notes : Should be translated before being returned, cchName
- has the size of the buffer, example strings: "ICQ", "AIM"
- }
- PS_GETNAME = '/GetName';
-
- {
- wParam : whichIcon
- lParam : 0
- Affect : Loads one of the protocol-sspecific icons
- Returns: the HICON or NULL on failure, the returned icon
- must be DestroyIcon()ed, the UI should overlay
- the online icon with further UI-specified icon to
- repressent the exact status mode.
- }
- PLI_PROTOCOL = $1; // An icon representing the protocol (eg the multicoloured flower for ICQ)
- PLI_ONLINE = $2; // Online state icon for that protocol (eg green flower for ICQ)
- PLI_OFFLINE = $3; // Offline state icon for that protocol (eg red flower for ICQ)
- PLIF_LARGE = $0; // Or with one of the above to get the large (32x32 by default) icon
- PLIF_SMALL = $10000; // Or with one of the above to get the small (16x16 by default) icon
-
- PS_LOADICON = '/LoadIcon';
-
- {
- wParam : status_mode
- lParam : Pointer to a null terminated string containing message
- Affect : Sets the status mode specific message for the user, see notes
- Returns: 0 on success, [non zero] on failure
- Notes : This service is not available unless PF1_MODEMSGSEND is set,
- and PF1_INDIVMODEMSG is *not* set.
- If PF1_INDIVMODEMSG is set, then see PSS_AWAYMSSG for details
- of operations of away messages.
- -
- Protocol modules smust support lParam=NULL, it may eithere mean
- to use an empty message or (preferably) not to reply at all to
- any requests.
- }
- PS_SETAWAYMSG = '/SetAwayMsg';
-
- {
- wParam : newMode from statusmodes.inc
- lParam : 0
- Affect : Change the protocol's status mode, see notes
- Returns: 0 on success, [non zero] on failure
- Notes : Will send an ack with :
- type=ACKTYPE_SUCCESS, result=ACKRESULT_SUCCESS, hProcess=previousMode, lParam=newMode
- -
- when the change completes. This ack is sent for all changes, not
- just ones caused by calling this function.
- -
- NewMode can be ID_STATUS_CONNECTING<=newMode<ID_STATUS_CONNECTING+
- MAX_CONNECT_RETRIES to signify that it's connecting and it's the nth retry.
- -
- Protocols are initially always in offline mode, if a protocol
- doesn't support a specific status mode, it should pick the closest
- ones that it does support, and change to that.
-
- If a protocol has to switch from offline mode to online (or a substate
- of online, like away) then it should report any errors in the
- form of an additional ack :
-
- type=ACKTYPE_LOGIN, result=ACKRESULT_FAILURE, hProcess=NULL, lParam=LOGINERR_*
-
- SetStatus() is called when a protocol module is first loaded
- with newMode=ID_STATUS_ONLINE.
- -
- Protocols can define their own LOGINERR_* starting at $1000, see
- LOGINERR_* above
- }
- PS_SETSTATUS = '/SetStatus';
-
- {
- wParam : 0
- lParam : 0
- Affect : Get the status mode that a protocol is currently in, see notes
- Returns: The current status mode
- Notes : Only protocol modules need to implement this, non network level
- protocol modules do not need to (but if you register as a protocol
- you need to, Miranda will GPF otherwise)
- }
- PS_GETSTATUS = '/GetStatus';
-
- {
- wParam : HDBEVENT
- lParam : 0
- Affect : allow 'somebody' to add the user to their contact list, see notes
- Returns: 0 on success, [non zero] on failure
- Notes : Auth request come in the form of an event added to the database
- for the NULL(0) user, the form is:
- -
- protocolSpecific: DWORD;
- nick, firstname, lastName, e-mail, requestReason: ASCIIZ;
- -
- HDBEVENT musts be the handle of such an event, one or more
- fields may be empty if the protocol doesn't support them
- }
- PS_AUTHALLOW = '/Authorize';
-
- {
- wParam : HDBEVENT
- lParam : Pointer to a null terminated string containing the reason, see notes
- Affect : Deny an authorisation request
- Returns: 0 on success, [non zero] on failure
- Notes : Protocol modules must be able to cope with lParam=NULL(0)
- }
- PS_AUTHDENY = '/AuthDeny';
-
- {
- wParam : 0
- lParam : Pointer to a null terminated string containing an ID to search for
- Affect : Send a basic search request, see notes
- Returns: A handle to the search request or NULL(0) on failure
- Notes : All protocols identify users uniquely by a single field
- this service will search by that field.
- -
- All search replies (even protocol-spec extended searches)
- are replied by a series of ack's,-
- -
- Result acks are a series of:
- type=ACKTYPE_SEARCH, result=ACKRESULT_DATA, lParam=Pointer to a TPROTOSEARCHRESULT structure
- -
- ending ack:
- type=ACKTYPE_SEARCH, result=ACKRESULT_SUCCESS, lParam=0
- -
- The pointers in the structure are not guaranteed to be
- valid after the ack is complete.
- -
- The structure to reply with search results can be extended
- per protocol basis (see below)
-
- }
- PS_BASICSEARCH = '/BasicSearch';
-
- {
- wParam : 0
- lParam : Pointer to a NULL terminated string containing the e-mail to search for
- Affect : Search for user(s) by e-mail address, see notes
- Returns: A HANDLE to the search, or NULL(0) on failure
- Notes : Results are returned as for PS_BASICSEARCH, this service
- is only available if the PF1_USERIDISEMAIL flag is set for caps --
- -
- This service with the above service should be mapped to the same
- function if the aforementioned flag is set.
- Version: v0.1.2.1+
- }
- PS_SEARCHBYEMAIL = '/SearchByEmail';
-
- {
- wParam : 0
- lParam : Pointer to a TPROTOSEARCHBYNAME structure
- Affect : Search for users by name, see notes
- Returns: Handle to the search, NULL(0) on failure
- Notes : this service is only available, if PF1_SEARCHBYNAME capability is set.
- Results are returned in the same manner as PS_BASICSEEARCH
- Version: v0.1.2.1+
- }
- PS_SEARCHBYNAME = '/SearchByName';
-
- {
- wParam : 0
- lParam : Handle to window owner
- Affect : Create the advanced search dialog box, see notes
- Returns: A window handle, or NULL(0) on failure
- Notes : this service is only available if PF1_EXTSEARCHUI capability is
- set, advanced search is very protocol-spec'd so it is left to
- the protocol itself to supply a dialog containing the options,
- this dialog should not have a titlebar and contain only search
- fields. the rest of the UI is supplied by Miranda.
- -
- The dialog should be created with CreateDialog() or it's kin
- and still be hidden when this function returns,
- -
- The dialog will be destroyed when the find/add dialog is closed
- Version: v0.1.2.1+
- }
- PS_CREATEADVSEARCHUI= '/CreateAdvSearchUI';
-
- {
- wParam : 0
- lParam : Handle to advanced search window handle
- Affect : Search using the advanced search dialog, see notes
- Returns: A handle or NULL(0) on failure
- Notes : Results are returned in the same manner as PS_BASICSEARCH,
- this service is only available if PF1_EXTSEARCHUI capability is set
- Version: v0.1.2.1+
- }
- PS_SEARCHBYADVANCED = '/SearchByAdvanced';
-
- {
- wParam : flags
- lParam : Pointer to a TPROTOSEARCHRESULT structure
- Affect : Adds a search result to the contact list, see notes
- Returns: A handle to the new contact (HCONTACT) or NULL(0) on failure
- Notes : The pointer MUST be a result returned by a search function
- since there maybe extra protocol-spec data required by the protocol.
- -
- the protocol module should not allow duplicate contains to be added,
- but if such a request *is* received it should return a HCONTACT
- to the original user,
- -
- If flags is PALF_TEMPORARY set, the contact should be added
- temorarily and invisiblely, just to get the user info (??)
- -
- }
- PS_ADDTOLIST = '/AddToList';
-
- {
- wParam : MAKEWPARAM(flags, iContact)
- lParam : HDBEVENT
- Affects: Add a contact to the contact list given an auth/added/contacts events, see notes
- Returns: A HCONTACT or NULL(0) on failure
- Notes : HDBEVENT must be either EVENTTYPE_AUTHREQ or EVENTTYPE_ADDED
- flags are the same as PS_ADDTOLIST,
- -
- iContacts is only used for contacts vents, it is 0-based index
- of the contacts in the event to add, there's no way to add two or more
- contacts at once, you should just call this as many times as needed.
- }
- PS_ADDTOLISTBYEVENT = '/AddToListByEvent';
-
- {
- wParam : InfoType
- lParam : Pointer to InfoData
- Affect : Changes user details as stored on the server, see notes
- Returns: A Handle to the change request or NULL(0) on failure
- Notes : the details stored on the server are very protocol spec'd
- so this service just supplies an outline for protocols to use.
- See protocol-specific documentation for what infoTypes are available
- and what InfoData should be for each infoTypes.
- -
- Sends an ack type=ACKTYPE_SETINFO, result=ACKRESULT_SUCCESS/FAILURE, lParam=0
- -
- This description just leaves me cold.
- Version: v0.1.2.0+
- }
- PS_CHANGEINFO = '/ChangeInfo';
-
- {
- wParam : HFILETRANSFER
- lParam : Pointer to a initalised TPROTOFILERESUME
- Affect : Informs the protocol of the user's chosen resume behaviour, see notes
- Returns: 0 on success, [non zero] on failure
- Notes : If the protocol supports file resume (caps: PF1_FILERESUME) then before
- each file receive begins it will broadcast an ack with :
-
- type=ACKTYPE_FILE, result=ACKRESULT_RESUME, hProcess=hFileTransfer,
- lParam = TPROTOFILETRANSFERSTATUS.
-
- If the UI processes this ack it must return a [non zero] valuee from it's
- hook, it all the hooks complete without returning [non zero] then the
- protocol will assume that no resume UI was available and will continue
- to receive the file with a default behaviour (default: overwrite)
- -
- If a hook does return [non zero] then that UI MUST call this service,
- PS_FILERESUME at some point.
- When the protocol module receives this call it will proceed wit the
- file recieve usingg the given information.
- -
- Having sasid that, PS_FILERESUME MUST be called, it is also
- acceptable to completely abort the transfer instead, i.e. the file
- exists locally and the user doesn't want to overwrite or resume or
- reget.
- Version: v0.1.2.2+
- }
- PS_FILERESUME = '/FileResume';
-
- // these should be called with CallContactService()
-
- {<</
- !IMPORTANT!
- wParam, lParam data expected declarations should be treated with
- one level of indirection, where it says (CCSDATA: Yes)
- should be :
-
- What you *actually* get in the service:
-
- wParam = 0
- lParam = pCCSDATA
-
- CCSDATA contains the ..wParam, ..lParam, hContact data declared with each service,
- so the wParam, lParam passed does not contain the data itself, but lParam
- contains a pointer to a structure which contains the data.
-
- />>}
-
- {
- CCSDATA: Yes
- wParam : flags
- Param : 0
-
- Affect : Updates a contact's details from the server, see notes
- Returns: 0 on success, [non zero] on failure
- Notes :
-
- flags which may have SGIF_MINIMAL set to only get
- "basic" information, such as nickname, email address.
-
- PCCSDATA(lParam)^.hContact has the HCONTACT handle to get user
- information for.
-
- Will update all the information in the database and then
- send acks with :
-
- type=ACKTYPE_GETINFO, result=ACKRESULT_SUCCESS, hProcess=nReplies, lParam=thisReply
- -
- Since some protocol do not allow the module to tell when it has
- got all the information so it can send a final ack, one
- ack will be sent after each chunk of data has been received,
- -
- nReplies contains the number of distinct acks
- that will be sent to get all the information, 'thisReply'
- is the zero based index of this ack.
- When thisReply=0 the minimal information has just been received,
- all other numbering is arbitrary.
-
- }
- PSS_GETINFO = '/GetInfo';
-
- {
- CCSDATA: Yes
- wParam : flags
- lParam : Pointer to a null terminated string
- Affect : Send an instant message
- Returns: an hProcess corresponding to an ACK which will be sent after
- the hProcess.
- Notes: type=ACKTYPE_MESSAGE, result=ACKRESULT_SUCCESS/FAILURE, lParam = 0
- -
- here's the deal, you must return a 'seq' from this service
- which you have to ack when the message actually get's sent,
- or send a fake ack sometime soon if you can't find out if the message
- was successfully received with the protocol that you're using.
- -
- this event is NOT added to the database automatically.
- }
- PSS_MESSAGE = '/SendMsg';
-
- {
- CCSDATA: Yes
- wParam : flags
- lParam : null terminated string to the URL, see notes
- Affect : Send a URL message, see notes
- Returns: A hProcess which will be ack'd later
- Notes : lParam may contain TWO strings, the first for URL, the second for
- description, in the format :
- <url>#0<desc>#0 or <url>#0#0
- Will send an ack for hProcess when the URL actually gets sent
- type=ACKTYPE_URL, result=ACKRESULT_SUCCESS/FAILURE, lParam=0
- -
- protocol modules are free to define flags starting at $10000
- -
- The event will *not* be added to the database automatically
- }
- PSS_URL = '/SendUrl';
-
- {
- CCSDATA: Yes
- wParam : MAKEWPARAM(flags)
- lParam : Pointer to hContactsList
- Affect : Send a set of contacts, see notes
- Returns: A hProcess which will be ack, NULL(0) on failure
- Notes : hContactsList is an array of nContacts handles to contacts,
- if this array includes one or more contains that can not be transferred
- using this protocol the function will fail.
- -
- Will send an ack when the contacts actually get sent:
-
- type=ACKTYPE_CONTACTS, result=ACKRESULT_SUCCESS/FAILURE, lParam=0
- -
- No flags have ben defined yet,
- -
- The event will *not* be added to the database automatically
- }
- PSS_CONTACTS = '/SendContacts';
-
- {
- CCSDATA: Yes
- wParam : 0
- lParam : 0
- Affect : Send a request to retrieve HCONTACT's mode message, see notes
- Returns: a hProcess which will be ack'd later, NULL(0) on failure
- Notes : the reply will come in a form of an ack :
-
- type=ACKTYPE_AWAYMSG, result=ACKRESULT_SUCCESS/FAILURE,
- lParam=pointer to a null terminated string the containing message
- }
- PSS_GETAWAYMSG = '/GetAwayMsg';
-
- {
- CCSDATA: Yes
- wParam : hProcess
- lParam : pointer to a buffer to fill with away message to reply with
- Affect : Sends an away message reply to a user, see notes
- Returns: 0 on success, [non zero] on failure
- Notes : This service must only be called is caps has PF1_MODEMSGSEND set
- as well as PF1_INDIVMODEMSG otherwise PS_SETAWAYMESSAGE should
- be used.
- -
- Reply will be sent in the form of an ack :
-
- type=ACKTYPE_AWAYMSG, result=ACKRESULT_SENTREQUEST, lParam=0
- }
- PSS_AWAYMSG = '/SendAwayMsg';
-
- {
- CCSDATA: Yes
- wParam : status_mode
- lParam : Pointer to a TPROTORECVEVENT structure
- Affect : An away message reply has been received
- }
- PSR_AWAYMSG = '/RecvAwayMsg';
-
- {
- CCSDATA: Yes
- wParam : status_mode
- lParam : 0
- Affect : Set the status mode the user will appear in to a user, see notes
- Returns: 0 on success, [non zero] on failure
- Notes : If status_mode = 0 then revert to normal state for the user,
- ID_STATUS_ONLINE is possible if PF1_VISLIST
- ID_STATUS_ONLINE is possible if PF1_INDIVSTATUS
- }
- PSS_SETAPPARENTMODE = '/SetApparentMode';
-
- // only valid if caps support IM xfers
-
- {
- CCSDATA: Yes
- wParam : HTRANSFER
- lParam : null terminated string containing the path
- Affect : Allow a file transfer to begin, see notes
- Returns: A handle to the transfer to be used from now on.
- Notes : If the path does not point to a directory then:
- if a single file is being transfered and the protocol supports
- file renaming (PF1_CANRENAMEFILE) then the file is given
- this name, othewise the file is removed and file(s) are placed
- into the resulting directory.
- -
- File transfers are marked by a EVENTTYPE_FILE added to the database.
- The format is :
- hTransfer: DWORD
- filename(s), description: ASCIIZ
- }
- PSS_FILEALLOW = '/FileAllow';
-
- {
- CCSDATA: Yes
- wParam : HTRANSFER
- lparam : Pointer to a buffer to be filled with reason
- Affect : Refuses a file transfer request
- Returns: 0 on success, [non zero] on failure
- }
- PSS_FILEDENY = '/FileDeny';
-
- {
- CCSDATA: Yes
- wParam : HTRANSFER
- lParam : 0
- Affect : Cancel an in-progress file transfer
- Returns: 0 on success, [non zero] on failure
- }
- PSS_FILECANCEL = '/FileCancel';
-
- {
- CCSDATA: Yes
- wParam : null terminated string containing description
- lParam : pointer to an array of pchar's containing file paths/directories
- Affect : Start a file(s) send, see notes
- Returns: A HTRANSFER handle on success, NULL(0) on failur
- Notes : All notifications are done thru acks :
- -
- type=ACKTYPE_FILE, if result=ACKRESULT_FAILED then
- lParam=null terminated string containing reason
- }
- PSS_FILE = '/SendFile';
-
- // Receiving Services
- {>>/
- Receiving Services:
- Before a message is sent to /RecvMessage it goes through a MS_PROTO_CHAINRECV
- which allows any other module to change data (for decryption, etc),
- this then reaches /RecvMessage.
-
- This does not have to be the same structure/memory contained within that
- structure that started the chain call.
-
- /RecvMessage adds the event to the database, any other modules who
- are interested in what message the user will see should hook at this point.
- />>}
-
- {
- CCSDATA: Yes
- wParam : 0
- lParam : Pointer to a TPROTORECVEVENT
- Affect : An instant message has beeen received, see notes
- Returns: 0
- Notes : lParam^.lParam^.szMessage has the message, see structure above
- stored as DB event EVENTTYPE_MESSAGE, blob contains message
- string without null termination.
- }
- PSR_MESSAGE = '/RecvMessage';
-
- {
- CCSDATA: Yes
- wParam : 0
- lParam : Pointer to a TPROTORECVEVENT, see notes
- Affect : A URL has been received
- Notes : szMessage is encoded the same as PSS_URL
- -
- Stored in the database : EVENTTYPE_URL, blob contains message
- without null termination
- }
- PSR_URL = '/RecvUrl';
-
- {
- CCSDATA: Yes
- wParam : 0
- lParam : Pointer to a TPROTORECVEVENT
- Affect : Contacts have been received, see notes
- Notes : pre.szMessage is actually a PROTOSEARCHRESULT list
- pre.lParam is the number of contains in that list.
- -
- PS_ADDTOLIST can be used to add contacts to the list
- -
- repeat [
- ASCIIZ userNick
- ASCIIZ userId
- ]
- userNick should be a human-readable description of the user. It need not
- be the nick, or even confined to displaying just one type of
- information.
- userId should be a machine-readable representation of the unique
- protocol identifying field of the user. Because of the need to be
- zero-terminated, binary data should be converted to text.
- Use PS_ADDTOLISTBYEVENT to add the contacts from one of these to the list.
- }
- PSR_CONTACTS = '/RecvContacts';
-
- {
- CCSDATA: Yes
- wParam : 0
- lParam : Pointer to a TPROTORECVFILE
- Affect : File(s) have been received
- }
- PSR_FILE = '/RecvFile';
+{<</
+ !IMPORTANT!
+ wParam, lParam data expected declarations should be treated with
+ one level of indirection, where it says (CCSDATA: Yes)
+ should be :
-{$ENDIF}
+ What you *actually* get in the service:
+
+ wParam = 0
+ lParam = pCCSDATA
+
+ CCSDATA contains the ..wParam, ..lParam, hContact data declared with each service,
+ so the wParam, lParam passed does not contain the data itself, but lParam
+ contains a pointer to a structure which contains the data.
+
+/>>}
+
+ {
+ CCSDATA: Yes
+ wParam : flags
+ Param : 0
+
+ Affect : Updates a contact's details from the server, see notes
+ Returns: 0 on success, [non zero] on failure
+ Notes :
+
+ flags which may have SGIF_MINIMAL set to only get
+ "basic" information, such as nickname, email address.
+
+ PCCSDATA(lParam)^.hContact has the HCONTACT handle to get user
+ information for.
+
+ Will update all the information in the database and then
+ send acks with :
+
+ type=ACKTYPE_GETINFO, result=ACKRESULT_SUCCESS, hProcess=nReplies, lParam=thisReply
+ -
+ Since some protocol do not allow the module to tell when it has
+ got all the information so it can send a final ack, one
+ ack will be sent after each chunk of data has been received,
+ -
+ nReplies contains the number of distinct acks
+ that will be sent to get all the information, 'thisReply'
+ is the zero based index of this ack.
+ When thisReply=0 the minimal information has just been received,
+ all other numbering is arbitrary.
+
+ }
+ PSS_GETINFO = '/GetInfo';
+
+ {
+ CCSDATA: Yes
+ wParam : flags
+ lParam : Pointer to a null terminated string
+ Affect : Send an instant message
+ Returns: an hProcess corresponding to an ACK which will be sent after
+ the hProcess.
+ Notes: type=ACKTYPE_MESSAGE, result=ACKRESULT_SUCCESS/FAILURE,
+ lParam=ansi error message or NIL
+ -
+ here's the deal, you must return a 'seq' from this service
+ which you have to ack when the message actually get's sent,
+ or send a fake ack sometime soon if you can't find out if the message
+ was successfully received with the protocol that you're using.
+ -
+ this event is NOT added to the database automatically.
+ }
+ PSS_MESSAGE = '/SendMsg';
+// PSS_MESSAGEW = '/SendMsgW';
+
+ {
+ CCSDATA: Yes
+ wParam : flags
+ lParam : null terminated string to the URL, see notes
+ Affect : Send a URL message, see notes
+ Returns: A hProcess which will be ack'd later
+ Notes : lParam may contain TWO strings, the first for URL, the second for
+ description, in the format :
+ <url>#0<desc>#0 or <url>#0#0
+ Will send an ack for hProcess when the URL actually gets sent
+ type=ACKTYPE_URL, result=ACKRESULT_SUCCESS/FAILURE,
+ lParam=ansi error message or NIL
+ -
+ protocol modules are free to define flags starting at $10000
+ -
+ The event will *not* be added to the database automatically
+ }
+ PSS_URL = '/SendUrl';
+
+ {
+ CCSDATA: Yes
+ wParam : MAKEWPARAM(flags)
+ lParam : Pointer to hContactsList
+ Affect : Send a set of contacts, see notes
+ Returns: A hProcess which will be ack, NULL(0) on failure
+ Notes : hContactsList is an array of nContacts handles to contacts,
+ if this array includes one or more contains that can not be transferred
+ using this protocol the function will fail.
+ -
+ Will send an ack when the contacts actually get sent:
+
+ type=ACKTYPE_CONTACTS, result=ACKRESULT_SUCCESS/FAILURE,
+ lParam=ansi error message or NIL
+ -
+ No flags have ben defined yet,
+ -
+ The event will *not* be added to the database automatically
+ }
+ PSS_CONTACTS = '/SendContacts';
+
+ {
+ CCSDATA: Yes
+ wParam : 0
+ lParam : 0
+ Affect : Send a request to retrieve HCONTACT's mode message, see notes
+ Returns: a hProcess which will be ack'd later, NULL(0) on failure
+ Notes : the reply will come in a form of an ack :
+
+ type=ACKTYPE_AWAYMSG, result=ACKRESULT_SUCCESS/FAILURE,
+ lParam=pointer to a null terminated string the containing message
+ }
+ PSS_GETAWAYMSG = '/GetAwayMsg';
+
+ {
+ CCSDATA: Yes
+ wParam : hProcess
+ lParam : pointer to a buffer to fill with away message to reply with
+ Affect : Sends an away message reply to a user, see notes
+ Returns: 0 on success, [non zero] on failure
+ Notes : This service must only be called is caps has PF1_MODEMSGSEND set
+ as well as PF1_INDIVMODEMSG otherwise PS_SETAWAYMESSAGE should
+ be used.
+ -
+ Reply will be sent in the form of an ack :
+
+ type=ACKTYPE_AWAYMSG, result=ACKRESULT_SENTREQUEST, lParam=0
+ }
+ PSS_AWAYMSG = '/SendAwayMsg';
+
+ {
+ CCSDATA: Yes
+ wParam : status_mode
+ lParam : 0
+ Affect : Set the status mode the user will appear in to a user, see notes
+ Returns: 0 on success, [non zero] on failure
+ Notes : If status_mode = 0 then revert to normal state for the user,
+ ID_STATUS_ONLINE is possible if PF1_VISLIST
+ ID_STATUS_ONLINE is possible if PF1_INDIVSTATUS
+ }
+ PSS_SETAPPARENTMODE = '/SetApparentMode';
+
+ // only valid if caps support IM xfers
+ {
+ CCSDATA: Yes
+ wParam : HTRANSFER
+ lParam : null terminated string containing the path
+ Affect : Allow a file transfer to begin, see notes
+ Returns: A handle to the transfer to be used from now on.
+ Notes : If the path does not point to a directory then:
+ if a single file is being transfered and the protocol supports
+ file renaming (PF1_CANRENAMEFILE) then the file is given
+ this name, othewise the file is removed and file(s) are placed
+ into the resulting directory.
+ -
+ File transfers are marked by a EVENTTYPE_FILE added to the database.
+ The format is :
+ hTransfer: DWORD
+ filename(s), description: ASCIIZ
+ }
+ PSS_FILEALLOW = '/FileAllow';
+ PSS_FILEALLOWW = '/FileAllowW';
+
+ {
+ CCSDATA: Yes
+ wParam : HTRANSFER
+ lparam : Pointer to a buffer to be filled with reason
+ Affect : Refuses a file transfer request
+ Returns: 0 on success, [non zero] on failure
+ }
+ PSS_FILEDENY = '/FileDeny';
+ PSS_FILEDENYW = '/FileDenyW';
+
+ {
+ CCSDATA: Yes
+ wParam : HTRANSFER
+ lParam : 0
+ Affect : Cancel an in-progress file transfer
+ Returns: 0 on success, [non zero] on failure
+ }
+ PSS_FILECANCEL = '/FileCancel';
+
+ {
+ CCSDATA: Yes
+ wParam : null terminated string containing description
+ lParam : pointer to an array of PAnsiChar's containing file paths/directories
+ Affect : Start a file(s) send, see notes
+ Returns: A HTRANSFER handle on success, NULL(0) on failur
+ Notes : All notifications are done thru acks :
+ -
+ type=ACKTYPE_FILE, if result=ACKRESULT_FAILED then
+ lParam=null terminated string containing reason
+ }
+ PSS_FILE = '/SendFile';
+ PSS_FILEW = '/SendFileW';
+
+ {
+ Send an auth request
+ wParam=0
+ lParam=TChar szMessage
+ Returns 0 on success, nonzero on failure
+ }
+ PSS_AUTHREQUEST = '/AuthRequest';
+ PSS_AUTHREQUESTW = '/AuthRequestW';
+
+ {
+ Send "User is Typing" (user is typing a message to the user) v0.3.3+
+ wParam=(WPARAM)(HANDLE)hContact
+ lParam=(LPARAM)(int)typing type - see PROTOTYPE_SELFTYPING_X defines in m_protocols.h
+ }
+ PSS_USERISTYPING = '/UserIsTyping';
+
+// Receiving Services
+{>>/
+ Receiving Services:
+ Before a message is sent to /RecvMessage it goes through a MS_PROTO_CHAINRECV
+ which allows any other module to change data (for decryption, etc),
+ this then reaches /RecvMessage.
+
+ This does not have to be the same structure/memory contained within that
+ structure that started the chain call.
+
+ /RecvMessage adds the event to the database, any other modules who
+ are interested in what message the user will see should hook at this point.
+/>>}
+ {
+ CCSDATA: Yes
+ wParam : 0
+ lParam : Pointer to a TPROTORECVEVENT
+ Affect : An instant message has beeen received, see notes
+ Returns: 0 - success, other failure
+ // handle to the newly added event, or NULL on failure
+ Notes : lParam^.lParam^.szMessage has the message, see structure above
+ stored as DB event EVENTTYPE_MESSAGE, blob contains message
+ string without null termination.
+ }
+ PSR_MESSAGE = '/RecvMessage';
+// PSR_MESSAGEW = '/RecvMessageW';
+
+ MS_PROTO_RECVMSG = 'Proto/RecvMessage';
+ {
+ CCSDATA: Yes
+ wParam : 0
+ lParam : Pointer to a TPROTORECVEVENT, see notes
+ Affect : A URL has been received
+ Notes : szMessage is encoded the same as PSS_URL
+ -
+ Stored in the database : EVENTTYPE_URL, blob contains message
+ without null termination
+ }
+ PSR_URL = '/RecvUrl';
+
+ {
+ CCSDATA: Yes
+ wParam : 0
+ lParam : Pointer to a TPROTORECVEVENT
+ Affect : Contacts have been received, see notes
+ Notes : pre.szMessage is actually a PROTOSEARCHRESULT list
+ pre.lParam is the number of contains in that list.
+ pre.flags can contain PREF_UTF defining the strings as utf-8 encoded (0.7.0+)
+ -
+ PS_ADDTOLIST can be used to add contacts to the list
+ -
+ repeat [
+ ASCIIZ userNick
+ ASCIIZ userId
+ ]
+ userNick should be a human-readable description of the user. It need not
+ be the nick, or even confined to displaying just one type of
+ information. The dbe.flags can contain DBEF_UTF defining userNick as
+ utf-8 encoded.
+ userId should be a machine-readable representation of the unique
+ protocol identifying field of the user. Because of the need to be
+ zero-terminated, binary data should be converted to text.
+ Use PS_ADDTOLISTBYEVENT to add the contacts from one of these to the list.
+ }
+ PSR_CONTACTS = '/RecvContacts';
+
+ {
+ CCSDATA: Yes
+ wParam : 0
+ lParam : Pointer to a TPROTORECVFILE
+ Affect : File(s) have been received
+ }
+ PSR_FILE = '/RecvFile';
+
+ MS_PROTO_RECVFILE :pAnsiChar = 'Proto/RecvFile';
+ MS_PROTO_RECVFILET:pAnsiChar = 'Proto/RecvFileT';
+
+ {
+ CCSDATA: Yes
+ wParam : status_mode
+ lParam : Pointer to a TPROTORECVEVENT structure
+ Affect : An away message reply has been received
+ }
+ PSR_AWAYMSG = '/RecvAwayMsg';
+
+ {
+ An authorization request has been received
+ wParam=0
+ lParam=(LPARAM)(PROTORECVEVENT*)&pre
+ pre.szMessage is same format as blob
+ pre.lParam is the size of the blob
+ }
+ PSR_AUTH = '/RecvAuth';
+
+{$ENDIF}
|