Trac is being migrated to new services! Issues can be found in our new
YouTrack instance and WIKI pages can be found on our
website.
- Timestamp:
-
Apr 15, 2007, 8:18:04 PM (17 years ago)
- Author:
-
ecoffey
- Comment:
-
--
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v14
|
v15
|
|
10 | 10 | * Re-examing and possibly re-implement signal-glue and API -glue code. |
11 | 11 | * Give .NET Purple objects the ability to actually update their C counterpart (or create one). |
12 | | Possible solution: Every api Object thats mapped to a purple object would inherit from Object.cs. Object.cs would have a !IntPtr pointing to the C structure (or null if this is a "new" object). Object would also have a sync() method which is responsible for updating the C struct its associated with (or making a new one and then populating it). |
| 12 | Possible solution: Every api Object thats mapped to a purple object would inherit from Object. Object would have a !IntPtr pointing to the C structure (or null if this is a "new" object). A potential constructor could look like: |
| 13 | {{{ |
| 14 | public class Object { |
| 15 | private IntPtr _c_structure = null; |
| 16 | Object(IntPtr struct) { |
| 17 | _c_structure = struct; |
| 18 | _updateFromStruct(); |
| 19 | } |
| 20 | } |
| 21 | }}} |
| 22 | And base classes could be responsible for implementing _updateFromStruct(). |
13 | 23 | * Right now delegates are invoked and just given an array of their data. Would be nice if we could explicitly state what they expect, e.g. {{{ OnBuddyStatusChanged(Buddy b, Status s) }}} |
14 | 24 | |
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!