pywin32-bugs Mailing List for Python for Windows Extensions (Page 90)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-03-05 04:52:59
|
Bugs item #1042471, was opened at 2004-10-08 05:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1042471&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin crashes when exiting. Initial Comment: Pythonwin crashes when I exit the program. My operating system is Windows XP. I had the same problem at installation as in bug 990048 and I followed the instructions, which fixed that problem. The only information I got from the crash was the Windows error popup. The program worked as expected before ending. I enclose a screen capture of the Windows error popups; this is the only response I got. (You cannot copy from these windows.) Python version: PythonWin 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright information. Pythonwin version: pywin32-202.win32-py2.4.exe ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 15:52 Message: Logged In: YES user_id=14198 This has recently been properly fixed - will be in 204 ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2004-10-16 19:33 Message: Logged In: YES user_id=364358 Appears partially "fixed" in build 203 in that I don't get the error message when the program ends. Maybe "covered is a better word, because the program is still not properly closed. 1. Recent files is not updated. 2. The little snake in the message tray still exists after the program exits. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1042471&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 04:43:07
|
Bugs item #1075751, was opened at 2004-11-30 14:38 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1075751&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Luke (luked) Assigned to: Nobody/Anonymous (nobody) Summary: SetConsoleCtrlHandler rejects ctrlHandler=None Initial Comment: The SetConsoleCtrlHandler function in the win32 api can be used to enable or disable ignoring of CTRL-C signals. This is done by passing NULL as the first parameter, as per the MSDN docs: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/setconsolectrlhandler.asp Unfortunately this doesn't work with win32api.SetConsoleCtrlHandler [pywin32 build 203]. It rejects "None" as the first parameter. The generated exception is: TypeError: First argument must be callable (got NoneType) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 15:43 Message: Logged In: YES user_id=14198 Checking in win32apimodule.cpp; new revision: 1.47; previous revision: 1.46 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1075751&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 04:15:18
|
Bugs item #1081112, was opened at 2004-12-08 16:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1081112&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Bryan (belred) Assigned to: Nobody/Anonymous (nobody) Summary: impossible to type the following Initial Comment: the following is impossible to type with auto-complete enabled for build 203, python 2.4. >>> class Foo(object): ... def x(self): pass ... def __getattribute__(self, name): ... print name ... raise AttributeError ... >>> f = Foo() >>> f.x when the dot is typed in the previous line you get the following, so it's impossible to type the x after the dot. >>> f.__dict__ __members__ __methods__ __class__ __class__ __class__ f. bryan ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 15:15 Message: Logged In: YES user_id=14198 The problem is the print statement in your code. Pythonwin asks your objects for attributes, and your code prints the attribute name as it is requested. There is nothing Pythonwin could do in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1081112&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 03:27:19
|
Bugs item #1089071, was opened at 2004-12-22 01:38 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1089071&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark E (markenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Debugging with debug build of Pythonwin loops with assert Initial Comment: Build debug version of Pythonwin (Pythonwin_d.exe) Run it. Create a test script like: ------------------------ def RunTest(): """Print something""" print "RunTest()" def main(): """Main entry point for module""" RunTest() if __name__ == "__main__": main() ---------------------- Put a breakpoint inside "RunTest()". Run in debugger. Stops at breakpoint correctly. Continue. ASSERT dialog box comes up referencing "thrdcore.cpp" line 173 which is part of MFC threading code. Referenced lines of code are: <code> #ifdef _DEBUG if (pState->m_nDisablePumpCount != 0) { TRACE(traceAppMsg, 0, "Error: CWinThread::PumpMessage called when not permitted.\n"); ASSERT(FALSE); } #endif </code> Not particularly severe in itself but might point at source of other bugs. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 14:27 Message: Logged In: YES user_id=14198 fixed in source - will be in build 204. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1089071&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 03:26:30
|
Bugs item #1077391, was opened at 2004-12-02 19:43 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1077391&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: excel typelib crashes python 2.4 Initial Comment: The .py file generated by makepy overflows the python compiler. This bug has always existed, and was triggered in older Python versions, but has re-surfaced in 2.4. Any Python version would trigger it given a large enough typelib. This crash does not happen if bForDemand=1 is passed to the makepy functions - that creates a seperate .py file for each interface. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 14:26 Message: Logged In: YES user_id=14198 Already fixed in source - will be in build 204 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1077391&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 03:25:43
|
Bugs item #1101347, was opened at 2005-01-13 13:01 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1101347&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Mark Hammond (mhammond) Summary: Docking toolbar AV at shut down Initial Comment: In pythonwin build 203, the CPythonWndFramework::_BaseOnClose method has a try/except handler which masks an access violation which occurs on shutdown. I believe the reason for the AV is this bug in MFC (specifically in DestroyDockBars): http://support.microsoft.com/default.aspx?scid=kb;EN-US;884030 Explicitly destroying the bars in MainFrame.OnClose (from intpyapp.py) seems to fix the problem: see the attached diff. By the way, I think something was going wrong with the exception handling in _BaseOnClose. When run under the VS 7.1 debugger, Pythonwin would end up jumping to an illegal address and faulting. I believe that it has not been shutting down correctly, and that's why it always left an icon in the taskbar. Along with the change to initpyapp, I took out the exception handler and rebuilt win32ui.pyd. Pythonwin seems to shut down correctly. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 14:25 Message: Logged In: YES user_id=14198 I've checked this in along with other fixes that should solve the registry problems. The checkin comment is below: Checking in win32uiExt.h; new revision: 1.6; previous revision: 1.5 Checking in pywin/debugger/debugger.py; new revision: 1.15; previous revision: 1.14 Checking in pywin/framework/intpyapp.py; new revision: 1.9; previous revision: 1.8 Hopefully a final fix for "[ 944506 ] PythonWin Menus don't work" and many other bugs relating to the registry filling up with toolbar registry entries. The problem was the fact that the debugging package dynamically created docable toolbars. When pythonwin started for the first time, references to these debugging toolbars caused MFC to get upset, and left the "stale" entries for those toolbars in the list. Later, when a debugging session started, these toolbars again got new entries which were written to the registry along with the old ones. Next startup, the cycle started again (but this time creating even more new ones, ignoring even more stale ones) Also incorporates [ 1101347 ] Docking toolbar AV at shut down from Greg Chapman, which was also reflected in other bugs relating to the task-bar icon remaining and the MRU menus not updating in Python 2.4. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 10:38 Message: Logged In: YES user_id=14198 Thanks - this looks great to me! I don't suppose you have any ideas on the docking toolbars? :) I've failed a few times now - I'll give it another quick go now. My most recent checkin to debugger.py should be reverted - it didn't solve the problem (although the ToolbarDebugging entries no longer leak, now only ToolbarDefault). Not saving the state at all is wrong though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1101347&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-04 23:52:52
|
Bugs item #1077864, was opened at 2004-12-03 07:10 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1077864&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Kay Schluehr (schluehrk) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin does not remember recent files Initial Comment: Intallation : ActiveState Python v.2.4.0 , pywin32-203.win32-py2.4 OS : Win2K, WinXP The recent file list will be erased when finishing/starting Pythonwin. Only the files currently loaded will be visible in the recent - section of the file menu. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 10:52 Message: Logged In: YES user_id=14198 This is the same as 1101347, which has a fix - so will be fixed in build 204 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1077864&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-04 23:51:52
|
Bugs item #1086260, was opened at 2004-12-16 16:28 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1086260&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: Tray Icon remains even if close PythonWin version-2.4.0 Initial Comment: PythonWin-2.4 Tray Icon in system Tray for Windows platform remains in the system Tray even if you close the application. If you open and close PythonWin application 10 times, you will see 10 tray icons. If you hover the mouse then only it goes off. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 10:51 Message: Logged In: YES user_id=14198 Tracking this in 1101347, as it has a patch that seems to work well and will be checked in. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2005-03-02 09:28 Message: Logged In: YES user_id=771074 Anybody else tried out the patch attached to bug # 1101347 yet ? It fixes this problem, and I've been using it for several weeks with no problems. Roger ---------------------------------------------------------------------- Comment By: Jason Drew (jason_drew) Date: 2005-03-01 13:22 Message: Logged In: YES user_id=1229717 I have observed the same bug: Pythonwin 2.4, on both Windows 2000 and Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1086260&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-04 23:50:27
|
Bugs item #1097153, was opened at 2005-01-06 23:51 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1097153&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Giovanni Bajo (giovannibajo) Assigned to: Nobody/Anonymous (nobody) Summary: DispatchWithEvents always rebuild makepy support Initial Comment: Hello, it looks like DispatchWithEvents has a bug and always rebuild the makepy support even if it is not necessary. The bug is here: if not disp.__dict__.get("CLSID"): # Eeek - no makepy support - try and build it. try: [...] The problem is the use of disp.__dict__ which is the dictionary instance. makepy generates objects which have their CLSID as a class attribute (rather than instance attributes). To fix this bug, it is sufficient to change this bug to the more straightforward and standard: if not getattr(disp, "CLSID"): # Eeek - no makepy support - try and build it. try: I'm not sure if the use of __dict__ was to avoid looking up in base classes (no clue about how win32com internally wraps COM objects). In that case, I suggest to use disp.__class__.__dict__ instead of disp.__dict__. Please, let me know in which official released version of win32all this fix will appear. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 10:50 Message: Logged In: YES user_id=14198 Fixed - thanks: new revision: 1.33; previous revision: 1.32 This will appear in build 204 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1097153&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-04 23:38:03
|
Bugs item #1101347, was opened at 2005-01-13 13:01 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1101347&group_id=78018 Category: pythonwin Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Mark Hammond (mhammond) Summary: Docking toolbar AV at shut down Initial Comment: In pythonwin build 203, the CPythonWndFramework::_BaseOnClose method has a try/except handler which masks an access violation which occurs on shutdown. I believe the reason for the AV is this bug in MFC (specifically in DestroyDockBars): http://support.microsoft.com/default.aspx?scid=kb;EN-US;884030 Explicitly destroying the bars in MainFrame.OnClose (from intpyapp.py) seems to fix the problem: see the attached diff. By the way, I think something was going wrong with the exception handling in _BaseOnClose. When run under the VS 7.1 debugger, Pythonwin would end up jumping to an illegal address and faulting. I believe that it has not been shutting down correctly, and that's why it always left an icon in the taskbar. Along with the change to initpyapp, I took out the exception handler and rebuilt win32ui.pyd. Pythonwin seems to shut down correctly. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 10:38 Message: Logged In: YES user_id=14198 Thanks - this looks great to me! I don't suppose you have any ideas on the docking toolbars? :) I've failed a few times now - I'll give it another quick go now. My most recent checkin to debugger.py should be reverted - it didn't solve the problem (although the ToolbarDebugging entries no longer leak, now only ToolbarDefault). Not saving the state at all is wrong though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1101347&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-04 22:38:45
|
Bugs item #1151485, was opened at 2005-02-25 12:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1151485&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: julian yap (jyap) Assigned to: Nobody/Anonymous (nobody) Summary: "Microsoft Access 10.0 Object Library" crashes python 2.4 Initial Comment: The .py file generated by makepy overflows the python compiler. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 09:38 Message: Logged In: YES user_id=14198 Dupe of #1085454 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1151485&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-04 22:36:41
|
Feature Requests item #1124115, was opened at 2005-02-17 04:36 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1124115&group_id=78018 Category: win32 Group: Next Release (example) Status: Open Resolution: None Priority: 5 Submitted By: Ian Storrs (ian_001) Assigned to: Nobody/Anonymous (nobody) Summary: Update Win32ras for new RAS functions Initial Comment: Update Win32ras to provide ability to fetch the RAS local and remote server IP addresses, read the RAS counters for a connection, and clear the RAS counters for a connection. This means updating WINVER, using the lastest ras.h include file from Microsoft, and checking that ras32api.dll is loaded at run time to avoid problems on older OS's i.e. anything other than Win2k and WinXP. Necessary code changes are below. I have built and verified these changes on Win32Extensions 2.03 with Python 2.3. #ifndef WINVER #define WINVER 0x500 #endif // @pymethod |win32ras|GetIpAddress|Returns a list of IP addresses. static PyObject * PyRasGetIpAddress( PyObject *self, PyObject *args ) { RASPPPIP lpprojection; HRASCONN hras; DWORD rc; DWORD bufsize; if (!PyArg_ParseTuple(args, "i:GetIpAddress", &hras)) // @pyparm int|hras||The handle to the RAS connection being checked. return NULL; RASCONNSTATUS cs; // @pyseeapi RasGetConnectStatus cs.dwSize = sizeof(RASCONNSTATUS); if ((rc=RasGetConnectStatus(hras, &cs ))) return ReturnRasError ("RasGetIpAddress",rc); // @pyseeapi RasGetConnectStatus if (!(cs.rasconnstate==RASCS_Connected)) return ReturnRasError ("RasGetIpAddress"); // @pyseeapi RasGetConnectStatus lpprojection.dwSize = bufsize = sizeof (RASPPPIP); // @pyseeapi RasGetErrorString if (rc=RasGetProjectionInfo (hras,RASP_PppIp,&lpprojection,&bufsize)) return ReturnRasError ("RasGetIpAddress",rc); return Py_BuildValue ("(ss)",lpprojection.szIpAddress, lpprojection.szServerIpAddress); } #if (WINVER >= 0x500) // @pymethod |win32ras|GetConnectionStatistics|Returns a list of RAS statistics. static PyObject * PyRasGetConnectionStatistics( PyObject *self, PyObject *args ) { RAS_STATS rasstats; HRASCONN hras; DWORD rc; DWORD bufsize; if (!PyArg_ParseTuple (args, "i:GetConnectionStatistics", &hras)) // @pyparm int|hras||The handle to the RAS connection being checked. return NULL; HINSTANCE hLib = LoadLibrary ("RASAPI32.DLL"); // Try to load the library if (hLib == NULL) return NULL; // Return NULL if RASAPI32.DLL is not loaded on the system FreeLibrary(hLib); RASCONNSTATUS cs; // @pyseeapi RasGetConnectStatus cs.dwSize = sizeof(RASCONNSTATUS); if ((rc=RasGetConnectStatus(hras, &cs ))) return ReturnRasError ("RasGetConnectionStatistics",rc); // @pyseeapi RasGetConnectStatus if (!(cs.rasconnstate==RASCS_Connected)) return ReturnRasError ("RasGetConnectionStatistics"); // @pyseeapi RasGetConnectStatus rasstats.dwSize = bufsize = sizeof (RAS_STATS); // @pyseeapi RasGetConnectionStatistics if (rc=RasGetConnectionStatistics (hras,&rasstats)) return ReturnRasError ("RasGetConnectionStatistics",rc); return Py_BuildValue ("(iiiiiiiii)",rasstats.dwBytesXmited, rasstats.dwBytesRcved, rasstats.dwCrcErr, rasstats.dwTimeoutErr, rasstats.dwAlignmentErr, rasstats.dwHardwareOverrunErr, rasstats.dwFramingErr, rasstats.dwBufferOverrunErr, rasstats.dwConnectDuration); } static PyObject * // @pymethod |win32ras|ClearConnectionStatistics|Clears ths RAS statistics and returns 1 if successful. PyRasClearConnectionStatistics( PyObject *self, PyObject *args ) { HRASCONN hras; DWORD rc; if (!PyArg_ParseTuple (args, "i:ClearConnectionStatistics", &hras)) // @pyparm int|hras||The handle to the RAS connection being checked. return NULL; HINSTANCE hLib = LoadLibrary ("RASAPI32.DLL"); // Try to load the library if (hLib == NULL) return NULL; // Return NULL if RASAPI32.DLL is not loaded on the system FreeLibrary(hLib); RASCONNSTATUS cs; // @pyseeapi RasGetConnectStatus cs.dwSize = sizeof(RASCONNSTATUS); if ((rc=RasGetConnectStatus(hras, &cs ))) return ReturnRasError ("RasClearConnectionStatistics",rc); // @pyseeapi RasGetConnectStatus if (!(cs.rasconnstate==RASCS_Connected)) return ReturnRasError ("RasClearConnectionStatistics"); // @pyseeapi RasGetConnectStatus // @pyseeapi RasGetConnectionStatistics if (rc=RasClearConnectionStatistics(hras)) return ReturnRasError ("RasClearConnectionStatistics",rc); BOOL bRet = 1; return Py_BuildValue("i", bRet); } #endif /* List of functions exported by this module */ // @module win32ras|A module encapsulating the Windows Remote Access Service (RAS) API. static struct PyMethodDef win32ras_functions[] = { {"CreatePhonebookEntry", PyRasCreatePhonebookEntry, METH_VARARGS}, // @pymeth CreatePhonebookEntry|Creates a new phonebook entry. The function displays a dialog box into which the user can enter information about the entry. {"Dial", PyRasDial, METH_VARARGS}, // @pymeth Dial|Establishes a RAS connection to a RAS server. {"EditPhonebookEntry", PyRasEditPhonebookEntry, METH_VARARGS}, // @pymeth EditPhonebookEntry|Creates a new phonebook entry. The function displays a dialog box into which the user can enter information about the entry {"EnumConnections", PyRasEnumConnections, METH_VARARGS}, // @pymeth EnumConnections|Returns a list of tuples, one for each active connection. {"EnumEntries", PyRasEnumEntries, METH_VARARGS}, // @pymeth EnumEntries|Returns a list of tuples, one for each phonebook entry. {"GetConnectStatus", PyRasGetConnectStatus, METH_VARARGS}, // @pymeth GetConnectStatus|Returns a tuple with connection information. {"GetEntryDialParams", PyRasGetEntryDialParams, METH_VARARGS}, // @pymeth GetEntryDialParams|Returns a tuple with the most recently set dial parameters for the specified entry. {"GetErrorString", PyRasGetErrorString, METH_VARARGS}, // @pymeth GetErrorString|Returns an error string for a RAS error code. {"HangUp", PyRasHangUp, METH_VARARGS}, // @pymeth HangUp|Terminates a remote access session. {"IsHandleValid", PyRasIsHandleValid, METH_VARARGS}, // @pymeth IsHandleValid|Indicates if the given RAS handle is valid. {"SetEntryDialParams", PyRasSetEntryDialParams, METH_VARARGS}, // @pymeth SetEntryDialParams|Sets the dial parameters for the specified entry. {"RASDIALEXTENSIONS", PyWinObject_NewRASDIALEXTENSIONS, METH_VARARGS}, // @pymeth RASDIALEXTENSIONS|Creates a new <o RASDIALEXTENSIONS> object {"GetIPAddress", PyRasGetIpAddress, METH_VARARGS}, // @pymeth GetIPAddress|Gets the PPP IP address for remote access session. #if (WINVER >= 0x500) {"GetConnectionStatistics", PyRasGetConnectionStatistics, METH_VARARGS}, // @pymeth GetConnectionStatistics|Gets the statistics for remote access connection. {"ClearConnectionStatistics", PyRasClearConnectionStatistics, METH_VARARGS}, // @pymeth GetConnectionStatistics|Gets the statistics for remote access connection. #endif {NULL, NULL} }; ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 09:36 Message: Logged In: YES user_id=14198 There is a win2kras module designed to avoid needing to LoadLibrary functions. Can you please reapply you patch to this module (and you can drop the LoadLibrary) Also, pyseeapi for ClearConnectionStatistics is wrong :) Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1124115&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-04 22:25:55
|
Bugs item #1119908, was opened at 2005-02-10 20:06 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 Category: win32 Group: None Status: Open Resolution: None >Priority: 5 Submitted By: oleaw (oleaw) Assigned to: Nobody/Anonymous (nobody) Summary: CastTo/QueryInterface problem Initial Comment: In the COM API I am using, the following is provided: To create a new patient object I have to cast the Patient manager interface to the IDIContstructor interface. PatMgr: IDIPatientMgr; NewPat: IDIPatient; ... PatMgr := DISession.GetManagerById(miPatient) as IDIPatientMgr; NewPat := (PatMgr as IDIConstructor).CreateNew as IDIPatient; //edit the patient... //Save the changes (NewPat as IDIEdit).Save; In python I have written the following code. miPerson = 26 try: PersonMgr except NameError: PersonMgr = self.__dips_api.GetManagerById(miPerson) else: print "PersonMgr eksisterer" NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') This casts PersonMgr to the right Interface. My problem is that once I use the CastTo function all of my other functions cease to work. Apparently all the objects are wrapped in PyIUnkown, and python is no longer able to find their appropriate type. This problem will persist until delete the automatically generated python COM code and restart IDLE. All the interfaces I am using are IDispatch. I have also tried to alternatively cast the interface with PersonMgr.QueryObject(IDIConstructor) and Dispatch(PersonMgr , None, 'IDIContructor'), but these functions are unable to find the interface. Have also tried with makepy Can anyone provide information on how to make CastTo work, (can I unwrap the PyIUnknown wrapper?) Ole A ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 09:25 Message: Logged In: YES user_id=14198 are you still having this problem? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-02-18 09:11 Message: Logged In: YES user_id=14198 You indicate you get back an IUnknown - can you call QueryInterface on this IUnknown for IDispatch? ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-17 00:07 Message: Logged In: YES user_id=1216110 The COM objects are written in Delphi ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-17 00:05 Message: Logged In: YES user_id=1216110 The following code corrects the problem in a similar function, but it does not help with the CreateNew function: Patient = PatientMgr.GetPatientById ('aakajf+0000005001392') Person = Dispatch(Patient, 'IDIPerson', '{F6C0D843- DEC8-4C31-A766-12CBE59F3184}', UnicodeToString=0) Person = Person._oleobj_.QueryInterface (pythoncom.IID_IDispatch) Person = Dispatch(Person) print Person.LastName ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-10 20:14 Message: Logged In: YES user_id=1216110 The line NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') is NewPerson = CastTo(PersonMgr, 'IDIConstructor') and IDIContructor should be IDIConstructor This however is not the problem Ole A ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-01 22:28:30
|
Bugs item #1086260, was opened at 2004-12-16 00:28 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1086260&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: Tray Icon remains even if close PythonWin version-2.4.0 Initial Comment: PythonWin-2.4 Tray Icon in system Tray for Windows platform remains in the system Tray even if you close the application. If you open and close PythonWin application 10 times, you will see 10 tray icons. If you hover the mouse then only it goes off. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2005-03-01 17:28 Message: Logged In: YES user_id=771074 Anybody else tried out the patch attached to bug # 1101347 yet ? It fixes this problem, and I've been using it for several weeks with no problems. Roger ---------------------------------------------------------------------- Comment By: Jason Drew (jason_drew) Date: 2005-02-28 21:22 Message: Logged In: YES user_id=1229717 I have observed the same bug: Pythonwin 2.4, on both Windows 2000 and Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1086260&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-01 02:22:17
|
Bugs item #1086260, was opened at 2004-12-16 00:28 Message generated for change (Comment added) made by jason_drew You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1086260&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dileep Nirala (dileep_nirala) Assigned to: Nobody/Anonymous (nobody) Summary: Tray Icon remains even if close PythonWin version-2.4.0 Initial Comment: PythonWin-2.4 Tray Icon in system Tray for Windows platform remains in the system Tray even if you close the application. If you open and close PythonWin application 10 times, you will see 10 tray icons. If you hover the mouse then only it goes off. ---------------------------------------------------------------------- Comment By: Jason Drew (jason_drew) Date: 2005-02-28 21:22 Message: Logged In: YES user_id=1229717 I have observed the same bug: Pythonwin 2.4, on both Windows 2000 and Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1086260&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-25 01:28:18
|
Bugs item #1151488, was opened at 2005-02-24 17:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1151488&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lenard Lindstrom (kermode) Assigned to: Nobody/Anonymous (nobody) Summary: Problem import in InteractivePythonApp.OnUpdateFileCheck Initial Comment: Pythonwin, built 203 for Python 2.4 running on Win98. The following module, which creates a customized import function, causes an endless stream of output to the PythonWin interactive window when imported. import __builtin__ _import = __import__ def MyImport(name, globs=None, locs=None, fromlist=None): print "Importing", name return _import(name, globs, locs, fromlist) __buitlin__.__import__ = MyImport The message printed repeatedly is 'importing scriptutils'. Extending the above module to the following: import __builtin__ from inspect import getframeinfo from sys import _getframe seen = set() _import = __import__ def MyImport(name, globs=None, locs=None, fromlist=None): if name not in seen: seen.add(name) filenm, lnno, funnm, src, posn = getframeinfo(_getframe(1), 1) print "-----------------" print "file:", filenm print "line:", lnno print "function:", funnm print src[posn] return _import(name, globs, locs, fromlist) __builtin__.__import__ = MyImport the problem is located to line 326 of module intpyapp.py, which is method OnUpdateFileCheck of class InteractivePythonApp. My guess is the output generated by the customized import handler triggers OnUpdateFileCheck which imports a module causing more output and so on. Here are two fixes among many: 1) Move the import of scriptutils in OnUpdateFileCheck to the module level. 2) Move the import to an __init__ function of InteractivePythonApp class InteractivePythonApp(app.CApp): def __init__(self): global __scriptutils import scriptutils as __scriptutils app.CApp.__init__(self) def OnUpdateFileCheck(self, cmdui): cmdui.Enable( __scriptutils.GetActiveFileName(0) is not None ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1151488&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-25 01:21:07
|
Bugs item #1151485, was opened at 2005-02-25 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1151485&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: julian yap (jyap) Assigned to: Nobody/Anonymous (nobody) Summary: "Microsoft Access 10.0 Object Library" crashes python 2.4 Initial Comment: The .py file generated by makepy overflows the python compiler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1151485&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-17 22:11:53
|
Bugs item #1119908, was opened at 2005-02-10 20:06 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 8 Submitted By: oleaw (oleaw) Assigned to: Nobody/Anonymous (nobody) Summary: CastTo/QueryInterface problem Initial Comment: In the COM API I am using, the following is provided: To create a new patient object I have to cast the Patient manager interface to the IDIContstructor interface. PatMgr: IDIPatientMgr; NewPat: IDIPatient; ... PatMgr := DISession.GetManagerById(miPatient) as IDIPatientMgr; NewPat := (PatMgr as IDIConstructor).CreateNew as IDIPatient; //edit the patient... //Save the changes (NewPat as IDIEdit).Save; In python I have written the following code. miPerson = 26 try: PersonMgr except NameError: PersonMgr = self.__dips_api.GetManagerById(miPerson) else: print "PersonMgr eksisterer" NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') This casts PersonMgr to the right Interface. My problem is that once I use the CastTo function all of my other functions cease to work. Apparently all the objects are wrapped in PyIUnkown, and python is no longer able to find their appropriate type. This problem will persist until delete the automatically generated python COM code and restart IDLE. All the interfaces I am using are IDispatch. I have also tried to alternatively cast the interface with PersonMgr.QueryObject(IDIConstructor) and Dispatch(PersonMgr , None, 'IDIContructor'), but these functions are unable to find the interface. Have also tried with makepy Can anyone provide information on how to make CastTo work, (can I unwrap the PyIUnknown wrapper?) Ole A ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-02-18 09:11 Message: Logged In: YES user_id=14198 You indicate you get back an IUnknown - can you call QueryInterface on this IUnknown for IDispatch? ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-17 00:07 Message: Logged In: YES user_id=1216110 The COM objects are written in Delphi ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-17 00:05 Message: Logged In: YES user_id=1216110 The following code corrects the problem in a similar function, but it does not help with the CreateNew function: Patient = PatientMgr.GetPatientById ('aakajf+0000005001392') Person = Dispatch(Patient, 'IDIPerson', '{F6C0D843- DEC8-4C31-A766-12CBE59F3184}', UnicodeToString=0) Person = Person._oleobj_.QueryInterface (pythoncom.IID_IDispatch) Person = Dispatch(Person) print Person.LastName ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-10 20:14 Message: Logged In: YES user_id=1216110 The line NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') is NewPerson = CastTo(PersonMgr, 'IDIConstructor') and IDIContructor should be IDIConstructor This however is not the problem Ole A ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-17 22:07:41
|
Bugs item #1085454, was opened at 2004-12-15 09:47 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1085454&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: sitecap (sitecap) Assigned to: Nobody/Anonymous (nobody) Summary: Py 2.4 + MS Excel COM --> crash Initial Comment: Any code that tries to dispatch an Excel (2003) application ends up crashing Python 2.4. (Used bForDemand=1 in makepy to generate MS Excel 11.0 Object Library, otherwise makepy itself crashes.) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-02-18 09:07 Message: Logged In: YES user_id=14198 This has been fixed in CVS by avoiding the generation of huge lines. ---------------------------------------------------------------------- Comment By: Brian Dorsey (briandorsey) Date: 2005-02-18 06:12 Message: Logged In: YES user_id=292730 Just wanted to note than I also see this crash, and that commenting out the mbcs encoding line in genpy.py seems to allow it work for me as well. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-01-26 20:32 Message: Logged In: YES user_id=14198 Thanks Roger - I'll dig a little deeper on this. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2005-01-26 16:27 Message: Logged In: YES user_id=771074 Python still crashes when you invoke one of the methods whose generated code caused the original crash. Looks to be related to this bug in the tokenizer: www.python.org/sf/1089395 It hits an assertion failure on lines longer than 512. For a workaround, remove the mbcs encoding tag in genpy.py and makepy works correctly even with bForDemand=0. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-01-25 20:53 Message: Logged In: YES user_id=14198 gencache.py (1.30) makepy.py (1.19) From that checkin message: Avoid crashes on Python 2.4 by defaulting to bForDemand=True - ie, each typelib actually creates a "skeleton" Python package, and populates the package as each interface is requested. Cause of the underling crash is that the generated .py causes an overflow as the byte-code is generated - something in 2.4 bloated the byte-code for these modules. ---------------------------------------------------------------------- Comment By: barney dalton (barneyd) Date: 2004-12-16 21:07 Message: Logged In: YES user_id=49828 I'm having a similar problem with Excel 2002 in Python 2.4. The script: #> from win32com.client import gencache gencache.EnsureModule('{00020813-0000-0000-C000-000000000046}', 0, 1, 3, bForDemand=1) import win32com.client ExcelApp=win32com.client.Dispatch("Excel.Application") #< Causes a access violation in python AppName: python.exe AppVer: 0.0.0.0 ModName: ntdll.dll ModVer: 5.1.2600.1217 Offset: 00033905 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1085454&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-17 19:13:07
|
Bugs item #1085454, was opened at 2004-12-14 14:47 Message generated for change (Comment added) made by briandorsey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1085454&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: sitecap (sitecap) Assigned to: Nobody/Anonymous (nobody) Summary: Py 2.4 + MS Excel COM --> crash Initial Comment: Any code that tries to dispatch an Excel (2003) application ends up crashing Python 2.4. (Used bForDemand=1 in makepy to generate MS Excel 11.0 Object Library, otherwise makepy itself crashes.) ---------------------------------------------------------------------- Comment By: Brian Dorsey (briandorsey) Date: 2005-02-17 11:12 Message: Logged In: YES user_id=292730 Just wanted to note than I also see this crash, and that commenting out the mbcs encoding line in genpy.py seems to allow it work for me as well. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-01-26 01:32 Message: Logged In: YES user_id=14198 Thanks Roger - I'll dig a little deeper on this. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2005-01-25 21:27 Message: Logged In: YES user_id=771074 Python still crashes when you invoke one of the methods whose generated code caused the original crash. Looks to be related to this bug in the tokenizer: www.python.org/sf/1089395 It hits an assertion failure on lines longer than 512. For a workaround, remove the mbcs encoding tag in genpy.py and makepy works correctly even with bForDemand=0. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-01-25 01:53 Message: Logged In: YES user_id=14198 gencache.py (1.30) makepy.py (1.19) From that checkin message: Avoid crashes on Python 2.4 by defaulting to bForDemand=True - ie, each typelib actually creates a "skeleton" Python package, and populates the package as each interface is requested. Cause of the underling crash is that the generated .py causes an overflow as the byte-code is generated - something in 2.4 bloated the byte-code for these modules. ---------------------------------------------------------------------- Comment By: barney dalton (barneyd) Date: 2004-12-16 02:07 Message: Logged In: YES user_id=49828 I'm having a similar problem with Excel 2002 in Python 2.4. The script: #> from win32com.client import gencache gencache.EnsureModule('{00020813-0000-0000-C000-000000000046}', 0, 1, 3, bForDemand=1) import win32com.client ExcelApp=win32com.client.Dispatch("Excel.Application") #< Causes a access violation in python AppName: python.exe AppVer: 0.0.0.0 ModName: ntdll.dll ModVer: 5.1.2600.1217 Offset: 00033905 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1085454&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-16 17:36:24
|
Feature Requests item #1124115, was opened at 2005-02-16 12:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1124115&group_id=78018 Category: win32 Group: Next Release (example) Status: Open Resolution: None Priority: 5 Submitted By: Ian Storrs (ian_001) Assigned to: Nobody/Anonymous (nobody) Summary: Update Win32ras for new RAS functions Initial Comment: Update Win32ras to provide ability to fetch the RAS local and remote server IP addresses, read the RAS counters for a connection, and clear the RAS counters for a connection. This means updating WINVER, using the lastest ras.h include file from Microsoft, and checking that ras32api.dll is loaded at run time to avoid problems on older OS's i.e. anything other than Win2k and WinXP. Necessary code changes are below. I have built and verified these changes on Win32Extensions 2.03 with Python 2.3. #ifndef WINVER #define WINVER 0x500 #endif // @pymethod |win32ras|GetIpAddress|Returns a list of IP addresses. static PyObject * PyRasGetIpAddress( PyObject *self, PyObject *args ) { RASPPPIP lpprojection; HRASCONN hras; DWORD rc; DWORD bufsize; if (!PyArg_ParseTuple(args, "i:GetIpAddress", &hras)) // @pyparm int|hras||The handle to the RAS connection being checked. return NULL; RASCONNSTATUS cs; // @pyseeapi RasGetConnectStatus cs.dwSize = sizeof(RASCONNSTATUS); if ((rc=RasGetConnectStatus(hras, &cs ))) return ReturnRasError ("RasGetIpAddress",rc); // @pyseeapi RasGetConnectStatus if (!(cs.rasconnstate==RASCS_Connected)) return ReturnRasError ("RasGetIpAddress"); // @pyseeapi RasGetConnectStatus lpprojection.dwSize = bufsize = sizeof (RASPPPIP); // @pyseeapi RasGetErrorString if (rc=RasGetProjectionInfo (hras,RASP_PppIp,&lpprojection,&bufsize)) return ReturnRasError ("RasGetIpAddress",rc); return Py_BuildValue ("(ss)",lpprojection.szIpAddress, lpprojection.szServerIpAddress); } #if (WINVER >= 0x500) // @pymethod |win32ras|GetConnectionStatistics|Returns a list of RAS statistics. static PyObject * PyRasGetConnectionStatistics( PyObject *self, PyObject *args ) { RAS_STATS rasstats; HRASCONN hras; DWORD rc; DWORD bufsize; if (!PyArg_ParseTuple (args, "i:GetConnectionStatistics", &hras)) // @pyparm int|hras||The handle to the RAS connection being checked. return NULL; HINSTANCE hLib = LoadLibrary ("RASAPI32.DLL"); // Try to load the library if (hLib == NULL) return NULL; // Return NULL if RASAPI32.DLL is not loaded on the system FreeLibrary(hLib); RASCONNSTATUS cs; // @pyseeapi RasGetConnectStatus cs.dwSize = sizeof(RASCONNSTATUS); if ((rc=RasGetConnectStatus(hras, &cs ))) return ReturnRasError ("RasGetConnectionStatistics",rc); // @pyseeapi RasGetConnectStatus if (!(cs.rasconnstate==RASCS_Connected)) return ReturnRasError ("RasGetConnectionStatistics"); // @pyseeapi RasGetConnectStatus rasstats.dwSize = bufsize = sizeof (RAS_STATS); // @pyseeapi RasGetConnectionStatistics if (rc=RasGetConnectionStatistics (hras,&rasstats)) return ReturnRasError ("RasGetConnectionStatistics",rc); return Py_BuildValue ("(iiiiiiiii)",rasstats.dwBytesXmited, rasstats.dwBytesRcved, rasstats.dwCrcErr, rasstats.dwTimeoutErr, rasstats.dwAlignmentErr, rasstats.dwHardwareOverrunErr, rasstats.dwFramingErr, rasstats.dwBufferOverrunErr, rasstats.dwConnectDuration); } static PyObject * // @pymethod |win32ras|ClearConnectionStatistics|Clears ths RAS statistics and returns 1 if successful. PyRasClearConnectionStatistics( PyObject *self, PyObject *args ) { HRASCONN hras; DWORD rc; if (!PyArg_ParseTuple (args, "i:ClearConnectionStatistics", &hras)) // @pyparm int|hras||The handle to the RAS connection being checked. return NULL; HINSTANCE hLib = LoadLibrary ("RASAPI32.DLL"); // Try to load the library if (hLib == NULL) return NULL; // Return NULL if RASAPI32.DLL is not loaded on the system FreeLibrary(hLib); RASCONNSTATUS cs; // @pyseeapi RasGetConnectStatus cs.dwSize = sizeof(RASCONNSTATUS); if ((rc=RasGetConnectStatus(hras, &cs ))) return ReturnRasError ("RasClearConnectionStatistics",rc); // @pyseeapi RasGetConnectStatus if (!(cs.rasconnstate==RASCS_Connected)) return ReturnRasError ("RasClearConnectionStatistics"); // @pyseeapi RasGetConnectStatus // @pyseeapi RasGetConnectionStatistics if (rc=RasClearConnectionStatistics(hras)) return ReturnRasError ("RasClearConnectionStatistics",rc); BOOL bRet = 1; return Py_BuildValue("i", bRet); } #endif /* List of functions exported by this module */ // @module win32ras|A module encapsulating the Windows Remote Access Service (RAS) API. static struct PyMethodDef win32ras_functions[] = { {"CreatePhonebookEntry", PyRasCreatePhonebookEntry, METH_VARARGS}, // @pymeth CreatePhonebookEntry|Creates a new phonebook entry. The function displays a dialog box into which the user can enter information about the entry. {"Dial", PyRasDial, METH_VARARGS}, // @pymeth Dial|Establishes a RAS connection to a RAS server. {"EditPhonebookEntry", PyRasEditPhonebookEntry, METH_VARARGS}, // @pymeth EditPhonebookEntry|Creates a new phonebook entry. The function displays a dialog box into which the user can enter information about the entry {"EnumConnections", PyRasEnumConnections, METH_VARARGS}, // @pymeth EnumConnections|Returns a list of tuples, one for each active connection. {"EnumEntries", PyRasEnumEntries, METH_VARARGS}, // @pymeth EnumEntries|Returns a list of tuples, one for each phonebook entry. {"GetConnectStatus", PyRasGetConnectStatus, METH_VARARGS}, // @pymeth GetConnectStatus|Returns a tuple with connection information. {"GetEntryDialParams", PyRasGetEntryDialParams, METH_VARARGS}, // @pymeth GetEntryDialParams|Returns a tuple with the most recently set dial parameters for the specified entry. {"GetErrorString", PyRasGetErrorString, METH_VARARGS}, // @pymeth GetErrorString|Returns an error string for a RAS error code. {"HangUp", PyRasHangUp, METH_VARARGS}, // @pymeth HangUp|Terminates a remote access session. {"IsHandleValid", PyRasIsHandleValid, METH_VARARGS}, // @pymeth IsHandleValid|Indicates if the given RAS handle is valid. {"SetEntryDialParams", PyRasSetEntryDialParams, METH_VARARGS}, // @pymeth SetEntryDialParams|Sets the dial parameters for the specified entry. {"RASDIALEXTENSIONS", PyWinObject_NewRASDIALEXTENSIONS, METH_VARARGS}, // @pymeth RASDIALEXTENSIONS|Creates a new <o RASDIALEXTENSIONS> object {"GetIPAddress", PyRasGetIpAddress, METH_VARARGS}, // @pymeth GetIPAddress|Gets the PPP IP address for remote access session. #if (WINVER >= 0x500) {"GetConnectionStatistics", PyRasGetConnectionStatistics, METH_VARARGS}, // @pymeth GetConnectionStatistics|Gets the statistics for remote access connection. {"ClearConnectionStatistics", PyRasClearConnectionStatistics, METH_VARARGS}, // @pymeth GetConnectionStatistics|Gets the statistics for remote access connection. #endif {NULL, NULL} }; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1124115&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-16 13:07:11
|
Bugs item #1119908, was opened at 2005-02-10 09:06 Message generated for change (Comment added) made by oleaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 8 Submitted By: oleaw (oleaw) Assigned to: Nobody/Anonymous (nobody) Summary: CastTo/QueryInterface problem Initial Comment: In the COM API I am using, the following is provided: To create a new patient object I have to cast the Patient manager interface to the IDIContstructor interface. PatMgr: IDIPatientMgr; NewPat: IDIPatient; ... PatMgr := DISession.GetManagerById(miPatient) as IDIPatientMgr; NewPat := (PatMgr as IDIConstructor).CreateNew as IDIPatient; //edit the patient... //Save the changes (NewPat as IDIEdit).Save; In python I have written the following code. miPerson = 26 try: PersonMgr except NameError: PersonMgr = self.__dips_api.GetManagerById(miPerson) else: print "PersonMgr eksisterer" NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') This casts PersonMgr to the right Interface. My problem is that once I use the CastTo function all of my other functions cease to work. Apparently all the objects are wrapped in PyIUnkown, and python is no longer able to find their appropriate type. This problem will persist until delete the automatically generated python COM code and restart IDLE. All the interfaces I am using are IDispatch. I have also tried to alternatively cast the interface with PersonMgr.QueryObject(IDIConstructor) and Dispatch(PersonMgr , None, 'IDIContructor'), but these functions are unable to find the interface. Have also tried with makepy Can anyone provide information on how to make CastTo work, (can I unwrap the PyIUnknown wrapper?) Ole A ---------------------------------------------------------------------- >Comment By: oleaw (oleaw) Date: 2005-02-16 13:07 Message: Logged In: YES user_id=1216110 The COM objects are written in Delphi ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-16 13:05 Message: Logged In: YES user_id=1216110 The following code corrects the problem in a similar function, but it does not help with the CreateNew function: Patient = PatientMgr.GetPatientById ('aakajf+0000005001392') Person = Dispatch(Patient, 'IDIPerson', '{F6C0D843- DEC8-4C31-A766-12CBE59F3184}', UnicodeToString=0) Person = Person._oleobj_.QueryInterface (pythoncom.IID_IDispatch) Person = Dispatch(Person) print Person.LastName ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-10 09:14 Message: Logged In: YES user_id=1216110 The line NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') is NewPerson = CastTo(PersonMgr, 'IDIConstructor') and IDIContructor should be IDIConstructor This however is not the problem Ole A ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-16 13:06:31
|
Bugs item #1119908, was opened at 2005-02-10 09:06 Message generated for change (Settings changed) made by oleaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 Category: win32 Group: None Status: Open Resolution: None >Priority: 8 Submitted By: oleaw (oleaw) Assigned to: Nobody/Anonymous (nobody) Summary: CastTo/QueryInterface problem Initial Comment: In the COM API I am using, the following is provided: To create a new patient object I have to cast the Patient manager interface to the IDIContstructor interface. PatMgr: IDIPatientMgr; NewPat: IDIPatient; ... PatMgr := DISession.GetManagerById(miPatient) as IDIPatientMgr; NewPat := (PatMgr as IDIConstructor).CreateNew as IDIPatient; //edit the patient... //Save the changes (NewPat as IDIEdit).Save; In python I have written the following code. miPerson = 26 try: PersonMgr except NameError: PersonMgr = self.__dips_api.GetManagerById(miPerson) else: print "PersonMgr eksisterer" NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') This casts PersonMgr to the right Interface. My problem is that once I use the CastTo function all of my other functions cease to work. Apparently all the objects are wrapped in PyIUnkown, and python is no longer able to find their appropriate type. This problem will persist until delete the automatically generated python COM code and restart IDLE. All the interfaces I am using are IDispatch. I have also tried to alternatively cast the interface with PersonMgr.QueryObject(IDIConstructor) and Dispatch(PersonMgr , None, 'IDIContructor'), but these functions are unable to find the interface. Have also tried with makepy Can anyone provide information on how to make CastTo work, (can I unwrap the PyIUnknown wrapper?) Ole A ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-16 13:05 Message: Logged In: YES user_id=1216110 The following code corrects the problem in a similar function, but it does not help with the CreateNew function: Patient = PatientMgr.GetPatientById ('aakajf+0000005001392') Person = Dispatch(Patient, 'IDIPerson', '{F6C0D843- DEC8-4C31-A766-12CBE59F3184}', UnicodeToString=0) Person = Person._oleobj_.QueryInterface (pythoncom.IID_IDispatch) Person = Dispatch(Person) print Person.LastName ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-10 09:14 Message: Logged In: YES user_id=1216110 The line NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') is NewPerson = CastTo(PersonMgr, 'IDIConstructor') and IDIContructor should be IDIConstructor This however is not the problem Ole A ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-16 13:05:17
|
Bugs item #1119908, was opened at 2005-02-10 09:06 Message generated for change (Comment added) made by oleaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 7 Submitted By: oleaw (oleaw) Assigned to: Nobody/Anonymous (nobody) Summary: CastTo/QueryInterface problem Initial Comment: In the COM API I am using, the following is provided: To create a new patient object I have to cast the Patient manager interface to the IDIContstructor interface. PatMgr: IDIPatientMgr; NewPat: IDIPatient; ... PatMgr := DISession.GetManagerById(miPatient) as IDIPatientMgr; NewPat := (PatMgr as IDIConstructor).CreateNew as IDIPatient; //edit the patient... //Save the changes (NewPat as IDIEdit).Save; In python I have written the following code. miPerson = 26 try: PersonMgr except NameError: PersonMgr = self.__dips_api.GetManagerById(miPerson) else: print "PersonMgr eksisterer" NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') This casts PersonMgr to the right Interface. My problem is that once I use the CastTo function all of my other functions cease to work. Apparently all the objects are wrapped in PyIUnkown, and python is no longer able to find their appropriate type. This problem will persist until delete the automatically generated python COM code and restart IDLE. All the interfaces I am using are IDispatch. I have also tried to alternatively cast the interface with PersonMgr.QueryObject(IDIConstructor) and Dispatch(PersonMgr , None, 'IDIContructor'), but these functions are unable to find the interface. Have also tried with makepy Can anyone provide information on how to make CastTo work, (can I unwrap the PyIUnknown wrapper?) Ole A ---------------------------------------------------------------------- >Comment By: oleaw (oleaw) Date: 2005-02-16 13:05 Message: Logged In: YES user_id=1216110 The following code corrects the problem in a similar function, but it does not help with the CreateNew function: Patient = PatientMgr.GetPatientById ('aakajf+0000005001392') Person = Dispatch(Patient, 'IDIPerson', '{F6C0D843- DEC8-4C31-A766-12CBE59F3184}', UnicodeToString=0) Person = Person._oleobj_.QueryInterface (pythoncom.IID_IDispatch) Person = Dispatch(Person) print Person.LastName ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-10 09:14 Message: Logged In: YES user_id=1216110 The line NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') is NewPerson = CastTo(PersonMgr, 'IDIConstructor') and IDIContructor should be IDIConstructor This however is not the problem Ole A ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-02-10 09:18:52
|
Bugs item #1119908, was opened at 2005-02-10 09:06 Message generated for change (Settings changed) made by oleaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 Category: win32 Group: None Status: Open Resolution: None >Priority: 7 Submitted By: oleaw (oleaw) Assigned to: Nobody/Anonymous (nobody) Summary: CastTo/QueryInterface problem Initial Comment: In the COM API I am using, the following is provided: To create a new patient object I have to cast the Patient manager interface to the IDIContstructor interface. PatMgr: IDIPatientMgr; NewPat: IDIPatient; ... PatMgr := DISession.GetManagerById(miPatient) as IDIPatientMgr; NewPat := (PatMgr as IDIConstructor).CreateNew as IDIPatient; //edit the patient... //Save the changes (NewPat as IDIEdit).Save; In python I have written the following code. miPerson = 26 try: PersonMgr except NameError: PersonMgr = self.__dips_api.GetManagerById(miPerson) else: print "PersonMgr eksisterer" NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') This casts PersonMgr to the right Interface. My problem is that once I use the CastTo function all of my other functions cease to work. Apparently all the objects are wrapped in PyIUnkown, and python is no longer able to find their appropriate type. This problem will persist until delete the automatically generated python COM code and restart IDLE. All the interfaces I am using are IDispatch. I have also tried to alternatively cast the interface with PersonMgr.QueryObject(IDIConstructor) and Dispatch(PersonMgr , None, 'IDIContructor'), but these functions are unable to find the interface. Have also tried with makepy Can anyone provide information on how to make CastTo work, (can I unwrap the PyIUnknown wrapper?) Ole A ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-10 09:14 Message: Logged In: YES user_id=1216110 The line NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') is NewPerson = CastTo(PersonMgr, 'IDIConstructor') and IDIContructor should be IDIConstructor This however is not the problem Ole A ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
