M/C Part 29 CLIPBOARDING ------------ Now I made great claims about clipboarding in the Driver manual. You know, stuff about cutting bits from one file/ application and pasting them in elsewhere. And I stand by it all - it is and will be a great facility, especially when more applications come out. And it's pretty darned easy to use. Essentially, the clipboard is just some memory, reserved like application data when it is needed and looked after by some Driver routines. There are two ways applications use it: Cutting (putting data on) and pasting (taking data off). To this end, there are four jump table entries, as I mentioned a few months back: " 120. JCUT: Cut BC bytes from HL onto the clipboard. BC must range from 1-256 and HL must be in the application page. CY is returned if the clipboard is full. (It can grow as long as memory allows) 123. JPASTE: Paste BC bytes from the clipboard to HL in the application page. BC must be from 1-256. CY is returned if there is no data left, with BC holding the number of bytes left unpasted. 126. JEMPTYCLIP: Empty clipboard, releasing all its pages, and reset the JCUT pointer to the start. 129. JRESETPASTE: Reset JPASTE pointer to the start of the clipboard. " These simply allow the application to wipe the clipboard clean, add some raw data onto the end and read the raw data back again. To structure things a bit better, we need rules to describe what the raw data represents. Let's call the things on the clipboard "objects": an object could be a piece of text, a picture or whatever. You can fill up the clipboard with as many objects as there are room for. Each object is given a four byte header: 0 Object type 1-3 Object length (excluding header) in page/ offset form. Since the clipboard is a serial store, to read an object later on, you have to read through all the ones before it. It might be the case that your application can only deal with certain data types, in which case you read the headers and skip over any unwanted ones, using the length in the header to guide you. At the moment, there are only two object types: 0 ASCII text, with Epson control codes. This is the type used by Notepad: the control code sequences begin with CHR$ 1 and end with CHR$ 3, with CHR$ 2 in between the numbers. This lets applications ignore control code strings should they wish. 1 Unmasked graphic block. A rectangular block, with some addition parameters after the header (these bytes are, of course, included in the length in the header): 0 Mode (0-3) 1 block width, in bytes. (0-255: the block need not necessarily fit on the screen) 2 block height, in lines. (0-255) 3.. graphic data, in raster lines one after the other. Of course, there can be more than 2 types! It's up to application writers to create new types and document them fully. Subsequent applications might want to be able to deal with these types, and thus the applications could share data. And before you ask, Notepad, alas, cannot cope with graphics. Yet. Using the four jump table entries is really easy, but the routines vary so much from application to application that it's pretty pointless giving you anything other than hints for your cut/ paste routines. Firstly, you have to do things in blocks of 256 bytes (or less) which means having a buffer space inside the application code. Before pasting, reset the internal paste pointer, and don't forget to empty the clipboard when necessary. Apart from that, it's really just a case of copying data from your appliction data pages to the clipboard and vice versa. I would suggest using at least three editing options: Cut (Copies the selection and removes it from the file) Copy (Copies the selection and does nowt else) Paste (Paste from the clipboard and then empty it) Notepad also has a "Multiple paste" option, which doesn't empty the clipboard. WRITING APPLICATIONS -------------------- Finally, after five or so months, we finally get to the bit about actually putting the theory into practice. I used SC_Assembler 256k on a 512k machine to create the source for my Driver applications: this leaves half of the memory untouched and available for Driver code and graphics, and application data. (NB. When I was writing the Driver code itself, I needed all 9 banks in SC_512, so I used an external meg for the File Manager data.) Anyway, using SC_256 meant installing Driver to page 16, and the Driver data to page 18, without the keyword (the system heap is filled by the assembler). My application object code was assembled to pages 1/2, so I poked EDITOR.FLAG with 1 (the first page number) before initialising Driver. Stuff about running Driver without the keyword is detailed in the manual. EDITOR.FLAG is at an offset of 1Eh into the Driver code, and on initialisation is copied into the second slot of the Driver application table, after File Manager. (Normally, its value is FFh, meaning "empty"). You can do this for any page you like, but page 1 seems obvious to me. Of course, until you put the application name at 80F0h and icon at 8100h, the Driver Desktop will show garbage, and before assembly any attempt to run the application would result in a bit of a crash! You can design the icon using Iconmaster. Finally, before even loading Driver, I reserved all the memory I was going to use with OPEN TO 16: CLEAR 25000 or something like that. This customised version of the assembler Basic let me assemble the source, and return directly to Driver to test it. Easy. So, there's nothing to stop you buying a copy and programming away right now. I expect that LERM and COMET can be altered similarly to have Driver in memory, so you have no excuses! DRIVER DATA ----------- Right, finally for this month, here are details of the Driver Data page. Some budding artists out there might want to re-draw so of the graphics, or the character set and create alternative driv??.dat files. It can also be useful (if a bit naughty!) for applications to fiddle with data directly. Sprites are in the form described for the pointer routines, and the icons are in the usual raster-line format. NB. REMEMBER THAT THE DATA PAGE NUMBER IS STORED IN SVAR 5C98h. Offset Description 0000 -07FF Sprites (2k) 0800 -0FFF Character set (2k) 1000 -27FF Window data tables (6k) 2800 -37FF Blocks, icons & other graphics (4k) 3800 -3FFF Workspaces (2k) SPRITES 0000 Arrow 00C6 Hourglass 01CC Arrowed cross 03F2 Caret CHARACTER SET The chars (ASCII 32-127) are stored as 16 byte blocks, using 4x8 fat pixels. Driver uses these as 3x7 fat pixels, so the two least significant bits, and the last 2 bytes, should be left blank. The data is NOT the same as with the ROM character set, in that the graphics are stored absolutely, in pen 3 on paper 0. (ROM sets are bit-mapped) WINDOW DATA TABLES The LSB of an address in a tables corresponds to the window number 0-255, except in the window order table and the names. 1000 Order table. 1100 Types: D0 Reset to clear the window when drawn. D1 Set for name. D2 Set for close gadget. D3 Set for move gadget. D4 Set for size gadget. D5 Set for x-scroll bar. D6 Set for y-scroll bar. D7 Set to make window selectively active. 1200 X coords (fat pixels). 1300 Y coords. 1400 X sizes (fat pixels). 1500 Y sizes. 1600 X-scroll bar positions. (0-255) 1700 Y-scroll bar positions. 1800 -27FF Names. (4k. 16 bytes per name) OTHER GRAPHICS 2800 -29FF 8x8 blocks. Each 32 bytes long. Numbered 0 - Move gadget 1 - Close gadget 2 - Size gadget 3 - Up gadget 4 - Down gadget 5 - Left gadget 6 - Right gadget 7 - Y scroll bar 8 - X scroll bar 9 - Scroll bar indicator 10 - Switch gadget (off) 11 - Switch gadget (on) 12 - Small file icon 13 - Small folder (closed) 14 - Small folder (open) 15 - Small folder (highlighted) 2A00 -2BFF Button icons. 32x16. 256 bytes each. 2A00 - Off 2B00 - On 2C00 -2FFF 16X16 icons. 128 bytes each. 2C00 - Attention (! in a triangle) 2C80 - Disk on blue background 2D00 - Disk on blue (highlighted) 2D80 - Printer 2E00 - Printer (highlighted) 2E80 - Disk on white 2F00 - Info. (i in an octagon) 2F80 - Question (? in octagon) 3000 -35FF 16x24 icons. 192 bytes each. 3000 - File Manager 30C0 - File 3180 - Folder 3240 - Folder (highlighted) 3300 - Bin (empty) 33C0 - Bin (full) 3480 - Bin (empty, highlighted) 3540 - Bin (full, highlighted) WORKSPACES Numbered 0-7. Each 256 bytes long at 256 byte intervals from 3800.