gokmase

You might be right on the 8 level limit, although a higher value isn't backfiring at least. I am quite aware you were seeking to redraw individual G_STRINGS and that is why I tried to explain how to do that without the transparency/overlay effect. If you follow my instructions the clipping rectangle of objc_draw() makes the call only output to the area you want (which is the rectangle occupied by the G_STRING). Yes, I did see your reply regarding v_bar solution for clearing the background but since I had already spent >30 minutes preparing an explanation on how to do it through the one simple objc_draw(), I decided to post anyway. In case you only need to perform full redraws, including the whole object tree at a time, then none of this is of course necessary.

Seems you get proper results from the objc_offset() call now. The overlay effect is back since you perform the objc_draw() call starting from the actual G_STRING object and then 3 levels down (which doesn't add anything since the G_STRING objects have no children). Essentially, you are not including the objects in the background at all. You can think of the G_STRING as a transparent object where only the actual text is being output upon objc_draw(). Hence, if you alter the text buffer contents of an object and then redraw only the actual object, it will not clear the background at all, but simply just output the new text contents on top of the old one. Easiest way to perform a redraw that takes care of this situation is to redraw from the root object (obj=0) and include as many levels of depth you can foresee is being used to reach down to the level your object is located. Usually a depth of 5 is more than enough, but make it 10 just to be sure if you want. Now the you have valid data to specify the clipping rectangle for your G_STRING objects, you can thus redraw *everything* from the root level down to your objects depth, but restrict the output by specifying the outer limits of the G_STRING in the clipping rectangle. tree& = address to object tree ob = index of the G_STRING object to redraw 0 = root object 10 = include child objects down to 10 levels depth x&, y& = absolute screen position as returned by objc_offset() w&, h& = height and width of the G_STRING object. You know how to find these out already junk = objc_offset(tree&,ob,x&,y&) junk = objc_draw(tree&,0,10,x&,y&,w&,h&) That should work. Again, chapter #6 in the Atari Compendium actually explains quite a lot on how things are tied together. I agree TOSHYP is a nice reference too (and is still being updated) but IMO the overall explanation of the system is much better described (and much easier to understand) in the Atari Compendium.

Well, the call you need to sort out to locate the area to redraw is for sure objc_offset. Considering it is just one call this should really not be a struggle. In my mind you might at this time want to consult Matt regarding any Hisoft Basic syntax aspects that needs attention for this to work out. I think we established how to do it principal, now it is a matter for you to sort out how to do it in Hisoft Basic and making sure variable postfix aren't causing any trouble.

The values for width/height (56,16) are definitely correct if you mean G_STRING objects in the left column, that can easily be verified by looking at the object data in an RSC-editor (I use RSM 3.651) Strings in the right column seems to have width/height 48,16 which makes sense since they hold one character less. You can find out the offsets to any part of the object structure by looking at the structure definition: (already posted back in post#23) typedef struct object { WORD ob_next; (obadr&+0) WORD ob_head; (obadr&+2) WORD ob_tail; (obadr&+4) UWORD ob_type; (obadr&+6) UWORD ob_flags; (obadr&+ UWORD ob_state; (obadr&+10) VOIDP ob_spec; (obadr&+12) WORD ob_x; (obadr&+16) WORD ob_y; (obadr&+18) WORD ob_width; (obadr&+20 WORD ob_height; (obadr&+22) } OBJECT; NOTE: The ob_x and ob_y values in the object structure specifies the objects position relative to its parent, hence not very useful to you at this time, since you need to know the absolute screen position of the objects you wish to redraw. I think a good way for you to proceed would be to download the Atari Compendium (http://dev-docs.atariforge.org/files/The_Atari_Compendium.pdf) and read through the AES chapter. Reading through the whole chapter would probably be good to get a better overview of the inner workings of the system. Make sure to pay extra attention to the sections covering "Resources" (6.13-6.23) and "Object library" and "Resource library" (6.115-6.129)

My initial thought is that if objc_offset() fills in the return values for x/y with 0/0 then one of these things might have happened: 1) Something went wrong with the actual objc_offset() call. Either a problem with using wrong variable name for either input or output, or overwriting the variable data by accident somewhere in between the call and the evaluation of the data. - Double check for typos on variable names! Also, verify that the returned value from objc_offset (stored in variable "junk" in your example) is filled with a non-zero value - if zero is returned then the objc_offset() call for some reason was unsuccessful. - And as noted before, do pay attention to if a variable might be accidently overwritten before evaluated - that happens all too easy.. 2) The object structure has been partly corrupted, and the area where its position is stored has been trashed. This is perhaps not that likely, but I suppose it could happen. - Try and see if it makes a difference if you make the objc_offset() call *before* manipulating the contents of any string buffer. 3) The object has in fact been moved legally to a x,y-position that corresponds with absolute position 0,0. I don't find this explanation very likely in this case though. A GEM program quickly gets very complex, and it is very easy to insert unwanted functionality by accident. Well, also known as a bug If we use the object #3 as an example, it is located inside object #2 that is a G_IBOX (probably used as a placeholder, to group together G_STRINGS, from obj #3 to obj #17, used for publishing test results). The parent of object #2 is a G_BUTTON, object #1. Now, if any part of the code alters the x,y-position of object #1 or object #2, this will of course affect the absolute position of object #3 as well. That said, this scenario is maybe not the most likely one to be responsible here. Regarding the redraw remark: In order to redraw the text without the transparency problem with the text, it is (as you noticed) not enough to redraw only the G_STRING itself. You need to include at least the parents from object #1 with a depth=2 for this to look right I think. (But for this redraw scheme to work as planned it is an absolute must to find out the correct (absolute) X,Y and width/height of the G_STRING object to use for the clipping rectangle in objc_draw, otherwise it will either redraw too much or too little.)

The size of the text buffers created upon RSRC_LOAD() are static, so beware of writing longer strings than those that are saved from RSC editor! In your example: Text buffer of object#3 can hold max 7 chars + null byte. Text buffer of object#19 can hold max 6 chars + null byte. First thing that happens if you write ascii chars past the limit of the buffer, is that you will trash the ending null byte, making it likely that you will find a longer text snippet than expected drawn to screen. (Sending an ascii byte to obspec%+7 will thus trash the ending null for object#3 in your case.) Writing further bytes beyond that limit will for sure cause corruption of any RSC data that follows the text buffer. Fun, fun

IIRC, issuing an OBJC_DRAW() for a G_STRING object will draw it in a transparent fashion, thus drawing the new (changed) text on top of the original one. You could work around that (the transparency "problem") by instead drawing the root object but including every child object down to depth of 3 (needed in this example) and then apply a clipping rectangle in size of our object. Something like this should work: obj&=3 ! The object we are targeting... ob_adr%=tree%+(obj&*24) ! Locate object address ob_w&=INT{ob_adr%+20} ! Find out width of our object ob_h&=INT{ob_adr%+22} ! Find out height of our object dummy%=OBJC_OFFSET(tree%,obj&,ob_x&,ob_y&) ! Find out the absolute position on screen for our object dummy%=OBJC_DRAW(tree%,0,3,ob_x&,ob_y&,ob_w&,ob_h&) ! Draw the root object (obj=0) and every child is contains down to max. 3 levels, limited by the clipping rectangle ob_x&, ob_y&, ob_w&, ob_h& (I tested this against the GEMBENCH.RSC and you do need to set the depth in objc_draw() to at least 3 in order for the call to reach from the root object to the child object we are targeting in this example) NOTE: The above is GFA-BASIC example code and as in previous examples, you will need to convert the variable postfixes to something better suited for Hisoft Basic

No, ob_spec is not pointing to an object at all, in this particular case it is pointing to the starting address of the text to be displayed. To be accurate ob_spec is a field that is *part* of the actual object structure, not pointing to the object. Depending on the object type ob_spec either contains: 1) A pointer to a TEDINFO structure (Object types: G_TEXT, G_BOXTEXT, G_FTEXT, G_FBOXTEXT) 2) A pointer to a BITBLK structure (Object type: G_IMAGE) 3) A pointer to a APPLBLK structure (Object type: G_PROGDEF) 4) A pointer to a ICONBLK or CICONBLK structure (Object types: G_ICON, G_CICON) 4) A pointer to a text buffer (Object types: G_BUTTON, G_STRING and G_TITLE) 5) A bit pattern (different for the respective object types) with various information regarding colour and borders, etc (Object types: G_BOX, G_BOXCHAR) Regards, /Joakim

Then I think we have found at least one reason why the example fails. My example was based on objects where OB_SPEC contains a pointer to a TEDINFO structure, as mentioned in post #19. For a G_STRING object the OB_SPEC field however contains a pointer directly to the text to be displayed. Regards, /Joakim

Out of curiosity, what object type is INF_FORM1? Regards, /Joakim

Not sure what is stirring up problems, but I have a hunch it may come down to the variable postfix type. In GFA you will find this to be true: Word & 2 bytes -32768 to 32767 Long % 4 bytes -2147483648 to 2147483647 In my example, anywhere a variable with postfix % is used, it refers to a LONG. And when a & is used, it refers to a WORD. I suspect the postfix types are not the same in Hisoft Basic. From one of your lines of working code, I get that you can store the address of a tree in tree&. Hence postfix "&" must mean a LONG (4 bytes). If that is correct, I would try to change the postfix of the variable you store the object address in: obadr& = tree& + (3*24) Regards, /Joakim

Hi Matt, Good to see you around again. You are for sure better suited to advice exxos on issues that involves coding in hisoft basic any day of the week! And furthermore, I think that any excuse that can bring an Atari out of the closet is a good one, so I'd say go with that Regards, /Joakim

RSRC_GADDR() is for most practical cases only ever used to find the address to the object tree(s). dummy%=RSRC_LOAD(0,tree_index&,tree_adr%) ! The address to the object tree (tree_index&) is then stored in tree_adr% But I realize that when coding for GFABASIC I have been spoiled with access to built in commands that offers shortcuts to individual objects and their structures, such as eg. OB_ADR and OB_SPEC. However, the object tree laytout is known: typedef struct object { WORD ob_next; WORD ob_head; WORD ob_tail; UWORD ob_type; UWORD ob_flags; UWORD ob_state; VOIDP ob_spec; WORD ob_x; WORD ob_y; WORD ob_width; WORD ob_height; } OBJECT; From this we can conclude that every object structure occupies exactly 24 bytes (same goes for the root object of course, since it too is an object). And I learned from a discussion earlier today that all the objects structures in a tree are stored one after the other, which means that we can locate the address of an individual object structure within a specified object tree by knowing its index: ob_adr%=tree_adr%+obj&*24 ! Start at the address where object tree begins, move 24 bytes forward for each object you wish to "skip". This line of code locates the address of the individual object. ob_spec%=LONG{ob_adr%+12} ! Essentially, 12 bytes into the individual object structure, you find the ob_spec field. Then we should be able to use the concept previously described: te_txtlen& = WORD{ob_spec%+24} ! Find the size of the text buffer attached to this object te_ptext% = LONG{ob_spec%+0} ! Find the address to the text buffer new_text$="Hello world" ! Find nice example text :-) new_text$=left$(new_text$,te_txtlen&) ! Make sure it fits the available buffer CHAR{te_ptext%}=new_text$ ! Update the text buffer with our brilliant example text (CHAR{} automatically adds en ending NULL byte) dummy%=OBJC_DRAW(tree_adr%,obj&,0,form_x&,form_y&,form_w&,form_h&) ! Draw the updated object contents to screen. Last 4 parameters consist the clipping rectangle. Oh, and I realize the above is GFABASIC code, but it should be dead simple to get the same scheme going with Hisoft Basic I think. Regards, /Joakim

I am afraid I can't help you with exactly how to proceed in Hisoft Basic. IIRC Matthew Bacon was devloping advanced GEM library routines back in the days, maybe he is still around in some of the forums? In GFA I would probably have done something like this: te_txtlen& = WORD{OB_SPEC(addr%,obj&)+24} ! Find the size of the text buffer attached to this object te_ptext% = LONG{OB_SPEC(addr%,obj&)+0} ! Find the address to the text buffer new_text$="Hello world" ! Find nice example text :-) new_text$=left$(new_text$,te_txtlen&) ! Make sure it fits the available buffer CHAR{te_ptext%}=new_text$ ! Update the text buffer with our brilliant example text (CHAR{} automatically adds en ending NULL byte) dummy%=OBJC_DRAW(addr%,obj&,0,form_x&,form_y&,form_w&,form_h&) ! Draw the updated object contents to screen. Last 4 parameters consist the clipping rectangle. Regards, /Joakim

Well, if you are trying to update the text of an object - what object type are you drawing in this example? For example, if you are drawing an object type that is either G_TEXT, G_BOXTEXT, G_FTEXT and G_FBOXTEXT then the OB_SPEC field contains a pointer to a TEDINFO structure. typedef struct text_edinfo { char * te_ptext; char * te_ptmplt; char * te_pvalid; WORD te_font; WORD te_fontid; WORD te_just; WORD te_color; WORD te_fontsize; WORD te_thickness; WORD te_txtlen; WORD te_tmplen; } TEDINFO; To alter the text of the above mentioned object types, you should start by finding out the current length of the text that was entered when the object was created in the RSC editor. Why? Well, when the RSC file was loaded through RSRC_LOAD() all buffers needed to store these text strings was stored in RAM together with all the rest of the RSC data. Hence, the default text for an object should be long enough for any text you wish to update the object with from the program. If you overflow such text buffers by entering too long text strings, you will corrupt the RSC data in ram. That is likely to trigger interesting stuff to show up on screen Find out length of text buffer for objects who use TEDINFO struct: te_txtlen = WORD{OB_SPEC(addr,obj)+24} To update the text buffer: Copy the new string data (including an ending NULL byte) to the address pointed to from OB_SPEC(addr,obj)+0 When the contents of the text buffer has been changed, you must of course issue an OBJC_DRAW() in order to make a visual change. (NOTE: For object type G_BUTTON the OB_SPEC field contains a pointer to the actual text buffer)

You shouldn't have to find out the direct address to an individual object to be able to draw it onto screen. Just use RSRC_GADDR() to find out the address to the tree in question, then draw any object inside this tree => OBJC_DRAW(tree,obj,depth,bx,by,bw,bh) tree = address to the object tree obj (WORD) = the objects number depth (WORD) = how many levels to include (use 0 if you don't need to include child objects, use 1 if you want to include child objects, use 2 if you wish to include child objects, and child objects to the child objects, etc) bx,by,bw,bh (WORD) = specifies the clipping rectangle which limits the graphical output To find out the coordinates of an object relative to its parent, you use OB_X(tree,obj) and OB_Y(tree,obj). For example: xpos=OB_X(tree,obj) It can also work the other way around, allowing you to set the coordinate of an object relative to its parent. For example: OB_X(tree,obj)=xpos If you need to find out an individual objects exact coordinates on screen you can use OBJC_OFFSET(tree,obj,xpos,ypos) The objects coordinates are then stored into xpos and ypos. Hope this information can be of some help. Regards, /Joakim

Personally I have learned most of what I know now about GEM through example code. Digesting other programmers code and understanding their solutions has been a great way for me to move forward I guess there is a chance you are at a disadvantage when it comes to finding existing GEM examples written in Hisoft Basic, but surely there ought to be something out there for you to find? Best of luck with continued work on your project! Regards, /Joakim

RSRC_GADDR() is supposed to return something other than zero if the command was carried out without problems, so if it returns "1" then that simply means "no error" According to the Atari Compendium, the address to the object tree (or individual object) sought for is filled in at the location pointed to by "addr". (See syntax below) rsrc_gaddr( type, index, addr ) WORD type, index; VOIDPP addr; I have no clue about the level of support for AES commands built into HiSoft Basic but considering this is standard stuff for any GEM app I assume it ought to look more or less identical to the syntax above. Regards, /Joakim

AtarICQ 0.174 is released Finally! A new release is now available, and for the first time in 4-5 years there is now a new OVL too The new OVL is more than anything else targetting some rather serious stability problems, some of which where causing problems exclusively under MiNTnet/gluestik, and then there was the one which prevented aICQ from running on a 68000 cpu. In other worse, this new version should be well worth a closer look, especially if you have had problems with stability or performance in the past! A huge thank you goes to Denis Huget who has made this new release possible by his great work on the OVL. THANKS! Important changes in the latest release: 1. AtarICQ is now able to cope with environment variable FONTSELECT when a full path is submitted instead of a process name. If a full path is sent, aICQ then tries to start the font selector (if not already running). 2. Fixed a bug in the contact list code that under some circumstances would cause a crash when swapping contacts by using up/down ARROWs. 3. Removed a debug messages that was accidently left in the final 0.173-release. It was a text message written to screen/console. 4. Fixad a small bug in the code for manually resorting (by dragging) of the TABs in the message window. 5. New feature added. The shortcut ALT+X will now trigger aICQ to remove all temporary contacts that exist at the time. The main benefit is to be able to quickly sweep your contact list clean from ICQ spammers. (Normally, you have all your contacts on the permanent list) 6. Slightly changed code for evaluating the status of online contacts. Should avoid confusion when it comes to clients using exotic status values. 7. New keyboard shortcut, ALT+H, will toggle the hiding of offline contacts. 8. OVL sources are branched from the 0089 version (newer sources were lost) 9. OVL tweaked to cure problem where a large SSI contact list would potentially cause the OVL to hit an infinite loop (thus freezing) 10. Speeded up the automatic requesting of basic user info to reval the nickname of UINs loaded from the SSI list. 11. Fixed a fatal bug which would strike under specific circumstances when requesting basic user info for a UIN, and the server didn't reply. (NOTE: The chase for this particular bug has been going on for 3-4 years, the challenge being that it was very hard to reproduce reliably) 12. OVL will now work better with 68000 CPU (no more odd address access) 13. Improved the routines keeping track of server requests, timeout of data, etc. 14. Fixed a problem with font size in the text input field for outgoing messages, striking under old Single TOS and standard AES/VDI. 15. Cured a small memory leak which happened when requesting extended user info. 16. Changed default behaviour: -Hiding offline contacts = OFF -Auto switch to new message = ON 17. AtarICQ now keeps track of incoming typing notifications, to be able to let them "time out" after a certain time of inactivity from the other end. This time is currently set to 20 seconds, after which the typing notification icon will be removed. 18. OVL can now successfully send messages to the AIM/ICQ-clone Trillian, which turned out to be rather picky. NOTE: At this time (2009-09-19) you might notice that some of your friends from your contact list aren't listed as online despite being very much logged on and available. The reason for this is more than likely that AtarICQ still doesn't posses the ability to update the server side list, hence all contacts not present there might be listed as offline at all times. The only way to solve this is to either use another ICQ client to update the list, or hold your breath until AtarICQ is able to do this.. Oh, and you can find the new release here: http://www.ataricq.org/ Have fun, and don't forget to share your thoughts on this relese with us, after all, feedback is what keeps things like this rolling.. Regards, /Joakim

Hi all, Following the 0.170 release in June earlier this year, there is now a new aICQ release ready for download. A good deal of small issues have been sorted out but there are a couple of additions made this time too. You can download the new release here: http://www.ataricq.org Compared to the previous official release: * A number of minor bugs sorted * In some popup menus it was not possible to select an entry in case either contact list or msg window was also open. Fixed now. * Fetching of contacts from the server side list had accidently been disabled in 0.170. It works now, but this needs to be reimplemented in the future. * Found and fixed a small bug that would result in form_wbutton() not being used under MagiC for handling of mouse clicks in background. * AtarICQ now use AV_STARTPROG instead of VA_START when: 1. Asking AV-SERVER to launch the Colour Selector (In Prefs./Contact list) 2. Asking AV-SERVER to replay sound sample files 3. Asking AV-SERVER to display history file (CTRL+H) 4. Asking AV-SERVER to display the help file (HELP)<br> (This should be good news to people who use other desktops than Thing) * A right click on an empty place in contact list will open up the popup menu with a listing of contacts, allowing you to "Create TAB for <nick>". (Also available through CTRL+T) * All popup menus that have window titles will now also have a CLOSER widget. Also, these popups can now also be moved like any other GEM window. * Using TAB or UP/DOWN-ARROW to jump to next text edit field in a dialog now works better under MagiC. SHIFT+TAB will now move focus backwards. Also, when we hit the last (or first, depending on TAB-direction) editable object of the dialog, focus will not wrap back to the first (or last) editable object. (This is in fact a workaround for MagiC's limited implementation of FORM_KEYBD) * Last AtarICQ release had a bug in the keyboard evaluation code that prevented user to type chars that required ALT-combinations. Should be OK now. * Adapted aICQ to some server changes on the ICQ-servers, making the logging in process a tad faster, and the updating of the contact list a lot smoother during it. Have fun, and please don't hesitate to send feedback! I hope there are a bunch of people out there still using the program, is that so? Smile Regards, /Joakim

My old STe once started behaving oddly at boot time, often reaching the GEM desktop but with the drive A: icon missing. After many hours of tests it turned out that the PSU had started to wear out. It was still working, but not providing quite enough power to feed the machine. Might be worth checking out perhaps, although you need to sort out any potential RAM-issue first.

Sweden, far up north (Piteå) (Falcon/CT60, TT030, MegaST4, STe, STfm)

I got a CT60 in my Falcon already, but would be cool with something to boost the TT with as well I'd take one.

Hi all, The series of interviews with people that have been playing a major part in the work with FreeMiNT and its components continues. This time the spotlight is put on the XaAES maintainer Odd Skancke, also known as "Ozk". Please visit the XaAES website to read the full interview: http://xaaes.atariforge.net Regards, /Joakim http://www.ataricq.org http://xaaes.atariforge.net http://topp.atari-users.net

Hi all, We would like to know what kind of interest there is in keeping FreeMiNT/XaAES compatible with Atari computers that lack the PMMU. There are some big changes coming, and Ozk needs to know if there is enough interest to justify the work needed to maintain compatibility with setups that lack the PMMU. So how many many Atari ST/e/fm users are still interested in running XaAES? Feel free to discuss this matter here, but to report your interest you should post a comment here too: http://www.atariforums.com/read.php?26,2285,2287#msg-2287 Regards, /Joakim