MemeCode - Blog

Page: 0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 ... 40 ... 45

Rich Edit Progress
Date: 9/8/2005	Well, after a lot of poking around with HTML rich text controls I can say that it certainly wasn't the easy solution I was looking for. I've tried both the IE and Mozilla control and they both have show stopper issues. IE Delete key doesn't work. Lots of weird duplicate p tags everywhere. Mozilla Layout of iframes can't be made to fill remaining space. 100% width and height are broken in that they get there dimensions off the body element instead of the parent div element. Meaning I can't resize the edit area to the client part of the window. Bug #303829 means you can't implement popup dialogs in Mozilla. No way of reliably calling javascript through the ActiveX interface. Meaning that to save the edited HTML back into a DOM accessable field you have to implement ugly hacks like retasking onmouseout to do the work for you and then programatically move the mouse out of the window. It only works with the 11mb Mozilla ZIP release, not the installer version of Mozilla or Firefox or the Mozilla ActiveX installer. That sucks. No way to get the size of the content without scrollbars to resize the window to fit everything in. So I have a "kinda" working solution with the Mozilla control but it still sucks in some parts. So I'm not keen to release it on unsuspecting users. I have learnt some cool new things though: You can disable scroll bars on an element by using the style "overflow: hidden;" There are special CSS colours that map to you current system colours. Very useful for creating UI elements that intergrate with the rest of an application. At least in Mozilla an iframe with "display: hidden;" still appears as empty space in the layout of elements. If you use "display: none;" then you can't address it anymore, it kinda disappears. Sooooo what I did is "width:0px; height:0px" until I needed it and then set it's size with javascript when I needed it. But you do that like this: ctrl.style.width = "100px"; ctrl.style.height = "80px"; instead of ctrl.width = "100px"; ctrl.height = "80px"; shrug.
(0) Comments \| Add Comment

Rich Edit Progress

Date: 9/8/2005

Well, after a lot of poking around with HTML rich text controls I can say that it certainly wasn't the easy solution I was looking for. I've tried both the IE and Mozilla control and they both have show stopper issues.

IE

Delete key doesn't work.
Lots of weird duplicate p tags everywhere.

Mozilla

Layout of iframes can't be made to fill remaining space. 100% width and height are broken in that they get there dimensions off the body element instead of the parent div element. Meaning I can't resize the edit area to the client part of the window.
Bug #303829 means you can't implement popup dialogs in Mozilla.
No way of reliably calling javascript through the ActiveX interface. Meaning that to save the edited HTML back into a DOM accessable field you have to implement ugly hacks like retasking onmouseout to do the work for you and then programatically move the mouse out of the window.
It only works with the 11mb Mozilla ZIP release, not the installer version of Mozilla or Firefox or the Mozilla ActiveX installer. That sucks.
No way to get the size of the content without scrollbars to resize the window to fit everything in.

So I have a "kinda" working solution with the Mozilla control but it still sucks in some parts. So I'm not keen to release it on unsuspecting users.

I have learnt some cool new things though:

You can disable scroll bars on an element by using the style "overflow: hidden;"
There are special CSS colours that map to you current system colours. Very useful for creating UI elements that intergrate with the rest of an application.
At least in Mozilla an iframe with "display: hidden;" still appears as empty space in the layout of elements. If you use "display: none;" then you can't address it anymore, it kinda disappears. Sooooo what I did is "width:0px; height:0px" until I needed it and then set it's size with javascript when I needed it. But you do that like this:
```
ctrl.style.width = "100px";
ctrl.style.height = "80px";
```
instead of
```
ctrl.width = "100px";
ctrl.height = "80px";
```
shrug.

(0) Comments | Add Comment

Scribe Rich Edit
Date: 5/8/2005	Ok, so don't assume this might work someday but this is NOT a mock up, it's a real screenshot. Technically it's RTE inside the Mozilla ActiveX Control as installed with the ZIP download of the Mozilla suite, hosted via ATL in C++... in a plugin. breathe Currently I have no way of getting the edited HTML back out of the control. But it's fun to play with.
(4) Comments \| Add Comment

Hosting Mozilla/IE in one page of C++
Date: 5/8/2005	I don't think anyone has put is as succiently as this before. It's written with ATL and you'll need to link with comsupp.lib but other than that it's pretty self contained. All you need to do is start using the IWebBrowser2 pointer 'Browser'.
(12) Comments \| Add Comment

Windows XP is only good for English
Date: 3/8/2005	I love windows ;) you just have to hand it to them for screwing it up royally. Lets see, Scribe had a problem receiving mail on 2k/XP systems where the user's username had an accent in the name. So I created an account called Máya and loaded up Scribe, sure enough it fails to receive mail. Then I get to the bottom of the problem, and the windows API call GetTempPath is returning the wrong path. Given that the path to the temp folder is: C:\\Documents and Settings\\Máya\\Local Settings\\Temp GetTempPath on XP no less returns you: C:\\DOCUME~1\\MAYA\\LOCALS~1\\Temp which doesn't actually exist because the username has been "ascii-fied". So I change the code to use GetTempPathW and try and compile. VC++ 6 falls over with the error message "can't create temp file". Hehehehehe. I wonder why! Then of course applications that use GetTempPath start breaking and doing weird things. Like some app, not sure which, decided in it's infinite wisdom that since the temp path doesn't exist... well it should CREATE it. Yeah that's the right thing to do... sure... so now you have the real temp path and an "ascii-fied" version. Which isn't going to confuse anyone or create problems... ;)
(0) Comments \| Add Comment

Windows XP is only good for English

Date: 3/8/2005

I love windows ;) you just have to hand it to them for screwing it up royally.

Lets see, Scribe had a problem receiving mail on 2k/XP systems where the user's username had an accent in the name. So I created an account called Máya and loaded up Scribe, sure enough it fails to receive mail. Then I get to the bottom of the problem, and the windows API call GetTempPath is returning the wrong path. Given that the path to the temp folder is:

C:\\Documents and Settings\\Máya\\Local Settings\\Temp

GetTempPath on XP no less returns you:

C:\\DOCUME~1\\MAYA\\LOCALS~1\\Temp

which doesn't actually exist because the username has been "ascii-fied".

So I change the code to use GetTempPathW and try and compile. VC++ 6 falls over with the error message "can't create temp file". Hehehehehe. I wonder why!

Then of course applications that use GetTempPath start breaking and doing weird things. Like some app, not sure which, decided in it's infinite wisdom that since the temp path doesn't exist... well it should CREATE it. Yeah that's the right thing to do... sure... so now you have the real temp path and an "ascii-fied" version. Which isn't going to confuse anyone or create problems... ;)

(0) Comments | Add Comment

Sluggish Computers
Date: 28/7/2005	It's probably just me but it seems like my computers are getting slower and slower. Or my expectations are getting higher or something. But it's getting quite annoying. I know what the problem is on my main box, a 1.4ghz athlon, apart from the aging CPU clock, it only has 512mb as RAM. Which XP sp2 barely runs on. Open a few apps and it starts swaping. I've been trying very hard to convince myself to not buy some more RAM and instead put the money towards a proper hardware upgrade, like a 4200+ and supporting mobo + ram. Anyway that sort of frustration was in the back of my mind when one Scribe user rolled back their install from v1.87 to v1.86 and mentioned how snappy the folder load times were. Which got me thinking, what happened to slow it down so much? So I whipped out the debugger, some trace code and profiled the load times of folders. All the time was going in reading email objects off disk. So I broke that down to disk read and parse time. The disk read was trivial, so I broke the parse down to field reading and post processing. Field reads were fine... but there was a huge amount of time lost in the post processing. So digging furthur I found some crusty old code in the mail account object that delt with storing and accessing the list of mail UID's still on the server. A quick rewrite of that and it's now all clean and modern (hmmm hashtables) and lo... behold... the folder load is "Teh Snappy(TM)" again. the crowd roars (available in test11)
(5) Comments \| Add Comment

New Scribe
Date: 26/7/2005	I'm almost ready to release a new build of Scribe with some fixes for SSL conectivity, HTML rendering, plugin brittle-ness and calendar bugs. But before I do I need to confirm some things with a beta tester. Thanks for being patient everyone.
(0) Comments \| Add Comment

Sitemap