| Blog |
|
| Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 42 43 44 45 46 47 48 49 50 ... 55 ... 60
| No Progress This Week | |
|---|---|
|
Date: 24/11/2006 | Well I have got nothing done on the coding front this week. Mostly due to a bad recurrence of RSI because the kids have been keeping us from getting any quality sleep. No sleep = no recovery from the day's activities.
Also on top of that I've had a number of good things happen this week. An old guitar amp that got stolen 7 years ago turned up on ebay last week and I spent a lot of time getting together the evidence that I owned it and presenting it to the Police. In the end I did get the amp back, but had to pay some money for it, a lot less than it was worth so I end up ahead. And also I bought a scooter to get around on after I sold my car 2 weeks ago. I have my next license test in what, like 10 days from now so I'm practicing riding like mad. It almost rained on me today and I'm not quite ready for riding in the wet, both from a gear perspective and a skills perspective. But at the end of the day it'll be a lot cheaper to run than a car which means our little family will have more left over for worth while things like renovating the house and putting the kids into a decent school. 
Hopefully next week we'll see some final touches on Scribe test8 and a release. |
| (7) Comments | Add Comment | |
| Scribe LDAP client plugin + libsasl.dll | |
|---|---|
|
Date: 14/11/2006 | I got a message recently that Scribe's LDAP plugin had 'acquired' a dependency on libsasl.dll, which I don't seem to bundle in the plugin download. This of course sucks for people trying to get it working. So I rejigged the plugin project file to build with a static version of libsasl which builds the library into the plugin itself. Which is a) smaller and b) more reliable than bundling the library as a separate DLL.
"Now sucks less!" |
| (0) Comments | Add Comment | |
| Car Sold | |
|---|---|
|
Date: 10/11/2006 | I sold my car today. Didn't get what I wanted for it, but near enough. And if I'd left it any longer I would've been up for more insurence. So it's probably all going to even out in the end.
I'm happy it's gone, and sad also because it's a great car and I enjoyed driving it. Time to move on. |
| (0) Comments | Add Comment | |
| SetWindowPlacement | |
|---|---|
|
Date: 8/11/2006 | The seemingly useful SetWindowPlacement Windows API call has been the bane of my life the last 2 days. In that it looks exactly like what I want it to do but it fails under the circumstances that I want to call it, which is inside the WM_CREATE message handler.
A little background, I want to add better window position save/restore functionality to Scribe, and I thought, well most of my apps will want this so why not patch it into LGI's GWindow object! So I did, but that also means it has to work. On my machine. On Joe Average's machine... and on Uber Cool Designer's machine with 3 monitors. You'd think that saving your window position and restoring it on the next session was easy right? Well aren't you in for a nasty surprise. Windows makes it well, difficult to get it right all the time. It's easy to write a 95% solution. But hard to get the edge cases working. One spectacular edge case is where you have a window mazimised. Not only do you need to save the fact it's mazimized but also where the window will restore to. This isn't so important on a single monitor machine but on a multi-monitor machine it controls where a window will maximize to. For instance, if you shut down an application maximized on the 2nd montior, and store only "was maximized" then when you open it again it'll be maximized on the first monitor. From what I can deduce, the restore position controls which monitor the SW_MAXIMIZE showCmd will send the window to. So enter GetWindowPlacement and SetWindowPlacement. They let you get the current minimized/maxmimized/normal state as well as the restored window position in workspace coordinates. Workspace coordinates are NOT screen coordinates, so they are not compatible with SetWindowPos or its ilk. So you'd be thinking now... yes yes... lets just save the WINDOWPLACEMENT structure to our settings hive and use that to restore the window on restart. Well thats good in theory but one runs into trouble in getting the settings to stick when using SetWindowPlacement inside the WM_CREATE handler. In the case that the window was maximized and you call SetWindowPlacement the call succeeds and your window maximized to the correct display. However when you restore the window during normal use you discover that the restore position has been lost and the window remains in the same position as it was when maximized. Nice. So after pulling it down to a bare test application and confirming this as behaviour built into Windows what do you do about it? How can we work around this? The best I've come up with so far is, call SetWindowPlacement once inside the WM_CREATE, and then at the end of your WM_CREATE post yourself a WM_USER message with a copy of the WINDOWPLACEMENT structure (dynamically allocated) and then when you receive that message, call SetWindowPlacement AGAIN to "fix" the restore position corrdinates. This is a bit of a kludge... but welcome to Windows. I might run into new and more difficult problems in saving/restoring window position/state as this code gets more field testing but at least for all the test cases I know about now it's good. |
| (1) Comment | Add Comment | |
| LgiRes/Scribe | |
|---|---|
|
Date: 3/11/2006 | About 2 weeks ago I got an email from a Scribe translator about how the some of the controls in the Scribe.lr8 file are too tiny to select and translate, this was because LgiRes had a bug that meant the controls moved around when you loaded the file again. In fixing that I ended up changing some of the way Lgi handled client/non-client regions in GView's that don't have an actual HWND (otherwise known as virtual views). Previous this had been a bit broken and in fixing it I had broken it properly. After hours of work I got sick of mucking with it and gave up. However this left the development build of LgiRes dead in the water. So I started using the build off the website. Which works but all the controls in the LayoutTable's move around randomly.
Then of course I had need to delete a control and it crashed. Bugger. I was trying to change the receive account UI in Scribe to have a specific field for the "Port" number because I'm sick to death of explaining to people what "Server[:Port]" means. So my grand idea was to make Port a separate field with a checkbox to enable it. And when it's not enabled its greyed out with "(default)" written in grey text. Sound good? Well at least it'll be bleedingly obvious I hope. Anyway I've been forced to fix LgiRes, which I got done today. One little question from a user sometimes triggers off weeks of work, refactoring code, fixing design/architecture issues, fixing fundamental parts of code that requires lots of testing. So when you're wondering why things sometimes take so long, thats why. Some changes are a few lines of code, some are many weeks of work spanning multiple software products and effecting API's, DLL's and my sanity. Next week will likely see the release of Scribe v1.89 test8, with all it's shiny new options code. I want to run it live a bit more now that the development is slowing down, see if there are any showstopping issues. PS the lr8 file format had a hard coded offset in the child controls that hang off a dialog. That has been removed in the latest LgiRes + Lgi builds. You just need to load/save you lr8 to update them to the new offset. |
| (0) Comments | Add Comment | |
| Progress | |
|---|---|
|
Date: 31/10/2006 | I've refactored the SSL implementation in Scribe v1.89 test7 a bit. Basically I reuse the one SSL_CTX object allocated with SSL_CTX_new for the lifetime of the application instead of for just one connection. I also made the mistake of deliberately freeing the SSL object that I retreived with BIO_get_ssl. Obviously that belongs to the BIO object or something, because when I freed the BIO object with BIO_free_all it seems to free the SSL object as well. And if you try and free the SSL object after that it crashes.
End result is that now it seems to be working fine. No crashes, just normal operation over time. I'm just keeping it connecting regularly to test it over the next few days. The state of the core components of Scribe is getting more stable now after ripping out the old options system and implementing a new one. There is one area that hasn't been fixed up yet and that is the plugins option storage. Currently they use this weird indexing system which won't be compatible with the new XML options file. So I'll have to rewrite that over the next day or 2, and then test it. There is now a new more robust method to save Window state (position and min/max) to an option file and built it into the GWindow object. This should mean that over the next release or 2 window positions become more reliable on a wider range of systems. Hand in hand with that I've fixed the "MoveOnScreen" method of the GView class to handle multiple monitors (at least on Win32) in an intellegent manner. And I plan to do the same sort of magic on the "MoveToCenter" method to avoid it going to the wrong screen or the edge of 2 screens. It should center on the same monitor as the other windows in the application. More or less. I'm playing with the idea of offering an option to store mail, contacts and other objects in a Maildir style folder instead of all in a mail2 file. This has some benifits and some drawbacks but I think the benifits outweigh the drawbacks. In the long term I'd like to move fully away from the mail2 file format. But I worry that some users need the benifits of it, especially people that use space limited USB drives will get hit with wasted space per node due to file system limitations. I don't know how bad that'll be yet but it might be a problem. The benifits are mainly, opportunity for corruption is very limited and easily fixed, you still benifit from being able to move large email around effortlessly, deletes are easy and quick (unlike MBOX) and it's mostly compatible with other mail clients that support maildir. It's tempting. One question I havn't fully answered is whether I should attempt to support both at the same time or just drop mail2 all together. You might like to weigh in with your opinion in the comments. |
| (2) Comments | Add Comment | |