MemeCode - Blog

Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 42 43 44 45 46 47 48 49 50 ... 55 ... 60 ... 65

Danger Will Robinson: EnumDisplayDevices
Date: 1/12/2006	In the documentation for EnumDisplayDevices it tells you that you need to initialize the cb parameter of DISPLAY_DEVICE to sizeof(DISPLAY_DEVICE), fair enough. That part is obvious. In XP you can do that and then call EnumDisplayDevices multiple times with the same DISPLAY_DEVICE structure and it works as you'd expect. But in Win2k it overwrites the cb parameter with a new larger value with every call to EnumDisplayDevices, so the 2nd call overwrites the stack and your app goes kaboom! So now you know.
(0) Comments \| Add Comment

Scripting Scribe
Date: 29/11/2006	Well after yakking on about scripting for so long I actually ran my first script using the new engine in Scribe this morning. The javascript style engine that initially appeared in the recent i.Mage release is now also being used in Scribe. Currently the only place you can write script is in the filter object's "Script" tab. For instance this script changes the background colour of email that match the filter conditions to red: if (Filter.TestConditions) { Mail.Colour = 0xffff0000; } Where the hex value is in the form "0xAARRGGBB", alpha, red, green, blue. Fairly standard stuff. The first part calls back into the filter object via the DOM mapping to test the conditions defined in the Conditions tab of the filter. This way you can customize the conditions even furthur or ignore the conditions entirely and just make up your own scripted conditions. But at least if you want to use the UI for conditions you can. You get 3 predefined variables, App = the application DOM object, Mail = the mail object being filtered and Filter = the filter object the script is attached to. Of course all that will be documented in time. I'm also thinking of having a application wide set of scripted event handlers so that you can hook events and execute scripts. This would allow you to customize various things like changing default settings on new mail or do something when the app starts. I really don't know what people will want to do yet but I'll just get it out there and see what people start hacking on to Scribe. I'm sure there will be a deluge of questions and scripts flying around for a while. Better get a release out eh! After fixing a bunch of bugs in the script engine this now works: Fd = GetFolder("/Inbox"); if (Fd) { Print("Got folder '" + Fd.Name + "'\n"); Child = CreateSubFolder(Fd, "Test", "Mail"); if (Child) { MoveItem(Child, Mail); } } It creates (or uses an existing) folder called 'Test' under the inbox and moves a matching email to that folder. You could for instance pull information out of the contact record associated with the sender to sort email into folders based on sender, creating more sub-folders if needed with this sort of script. The "Print" command outputs to a new scripting console window that is hidden by default but you can show it using Tools -> Debug -> Show Scripting Console. What would you want to do with scripted filters?
(3) Comments \| Add Comment

Scripting Scribe

Date: 29/11/2006

Well after yakking on about scripting for so long I actually ran my first script using the new engine in Scribe this morning. The javascript style engine that initially appeared in the recent i.Mage release is now also being used in Scribe. Currently the only place you can write script is in the filter object's "Script" tab. For instance this script changes the background colour of email that match the filter conditions to red:

if (Filter.TestConditions)
{
    Mail.Colour = 0xffff0000;
}

Where the hex value is in the form "0xAARRGGBB", alpha, red, green, blue. Fairly standard stuff. The first part calls back into the filter object via the DOM mapping to test the conditions defined in the Conditions tab of the filter. This way you can customize the conditions even furthur or ignore the conditions entirely and just make up your own scripted conditions. But at least if you want to use the UI for conditions you can. You get 3 predefined variables, App = the application DOM object, Mail = the mail object being filtered and Filter = the filter object the script is attached to. Of course all that will be documented in time.

I'm also thinking of having a application wide set of scripted event handlers so that you can hook events and execute scripts. This would allow you to customize various things like changing default settings on new mail or do something when the app starts. I really don't know what people will want to do yet but I'll just get it out there and see what people start hacking on to Scribe. I'm sure there will be a deluge of questions and scripts flying around for a while.

Better get a release out eh!

After fixing a bunch of bugs in the script engine this now works:

Fd = GetFolder("/Inbox");
if (Fd)
{
    Print("Got folder '" + Fd.Name + "'\n");
	
    Child = CreateSubFolder(Fd, "Test", "Mail");
    if (Child)
    {
        MoveItem(Child, Mail);
    }
}

It creates (or uses an existing) folder called 'Test' under the inbox and moves a matching email to that folder. You could for instance pull information out of the contact record associated with the sender to sort email into folders based on sender, creating more sub-folders if needed with this sort of script.

The "Print" command outputs to a new scripting console window that is hidden by default but you can show it using Tools -> Debug -> Show Scripting Console.

What would you want to do with scripted filters?

(3) Comments | Add Comment

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

Sitemap