Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I am currently working on integrating plplot (5.9.0) on a Windows application compiled with MinGW. I have had trouble with the WinGCC device, and, even though I am trying to cope with it by improving wingcc.c, I am very new to the W32 API and more generally the way plplot works internally. Of course, if I succeed in my improvements, I will submit them here.
- When many streams are displayed at once, only one of them is refreshed properly. The good behaviour is obtained by forcing dev->waiting=1 in the Resize() function before the first "if", but of course this is an ugly "fix" as it overrides lots of stuff. Any suggestion as how to improve this?
- If I understand well the way plplot works, no matter how many streams will be created, the pls variable always points to the first stream. And WinGCC uses this variable, allowing only the first window to behave properly (refresh, menus, events). Please tell me I am wrong, because this would require some major rewrites to get this sorted.
- Any plan to have cursor acquisition working on WinGCC (PLESC_GETC in plD_esc_wingcc)? I cannot use plplot as I wish without this. As I said earlier, I will try to implement it, but as I am very new to the W32 API, my solution may be quite less elegant than that of the wingcc layer developers.
- Example x29c crashes on MinGW :) The problem lies deeeeep inside the code, in pldtfac (pldtik.c). x29c eventually calls this function using a negative vmin, which is passed to gmtime. On Linux, gmtime accepts pointers to negative ISO times (before 01/01/1970). On MinGW it crashes. I know this is a MinGW bug, but it could be a good idea to put some safety checks around gmtime calls.
Forget my second remark, I got confused by the fact that in WinGCC, when 2 windows are open, even though the 2 streams are different, the window handles (dev->hwnd) end up being the same in plD_eop_wingcc. But I have to have a closer look to find out why... This is obviously a wrong behaviour as, for example, the TrackPopupMenu call in plD_eop_wingcc may not call the menu on the good window!