Overall, I'd say these are the most boring and thought-intensive parts of DCS6, even more than the networking stuff. Part of the problem is there is a ton of stuff to set up: even though I have a lot of code left over from that unreleased beta of Document DE 5, I had to set up an entirely separate part of the GUI stack to handle mouse items, rewrite the mouse routines to handle interactive cursors and hotspots, and define all the onclick methods. Right now I've done a lot of the setup and begun the onclick thing. Right now it figures out where you're clicking if it's in a single-line text box, whic is mostly fixed after about 6 hours of debugging. Watch the last parts of this closely:

...cool? I suppose it's superb if it gets us 1 step closer to DCS6.

It is indeed. The problem is that I must design and code this within 2 weeks' time:

http://www.cemetech.net/img/dcs/dcs6/gui/TxtFlow.tif

Kerm using a .tif?!

it is odd, that and are we supposed to be able to read that?

Windows journal only exports .tif and .pdf. :/ I'll try the pdf.

pdfs... as in adobe pdfs? ick...

Anyways, good luck with that flow chart, it looks confusing... o.O

http://www.cemetech.net/doorscs/docs/TxtFlow.pdf

I thought you didn't have due dates.

My internal ones are:

>7/15/06: Interactive Text routines
>8/1/06: Remaining interactive routines
>9/1/06: Cn2
>Rest of year: gCn, documentation, bugtesting

OMG the 1337th thread starts with something about boring! OMG!

P.S. This is topic 1337, lol

Boring? This is hardly boring. This will make you able to make a basic text editor with a mere 100 bytes or so of code.

What is this then?

I think he meant development wise, that will be the most boring of it.

Boring for me to design and code; certainly not boring for the user to use! With this, web pages with text input, text editors, and anything that requires input of text is possible.

Edit: [2:39am, 7/4/06] It turns out that TASM has a limit to the number of lables it can support. Specifically, not that much higher than 1,671 labels. I have now been spending time writing my own custom include to try to cut that down as much as possible.

*bump*
Well, it's not really functional, but I have the entire framework in place, ready to be build upon and debugged.

That is awesome. Are you going to mplement restore and maximize buttons sometime in the future?

Instead of wasting time doing that, why don't you just use Brass instead?

Chipmaster: too time-consuming to convert all my code
bfr:

I didn't realize that it used a different syntax. I've never tried it myself, but I had heard it was backwards compatible to TASM code. I guess I was misinformed...