Hisoft basic users ?

[gokmase]

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)

Edited July 4, 2015 by gokmase

[exxosuk]

http://toshyp.atari.org/en/008010.html That's the site I have been using so far.

 

So 56,16 is correct, I did not see the relation to the 2 numbers, as if the box was 16 high for a letter, than 6 letters would / should be more like 96. So will ignore those figures if they are correct.

 

So I need to work on the X & Y problem. I did try using obadr& instead of tree, but nothing worked. In fact it was a mix of doing nothing at all, or crashing. I did not try getting the values before changing the text, but that is something i can try. It is possible changi.ng the text corrupted something, but not sure why as it seems to change the string data fine.

[gokmase]

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.

[exxosuk]

0             0 
 1             18 
 2             255 
 3             255 
 4             255 
 5             255 
 6             0 
 7             28 
 8             0 
 9             0 
 10            0 
 11            0 
 12            0 
 13            17 
 14            142 
 15            49 
 16            0 
 17            0 
 18            0 
 19            224 
 20            0 
 21            56 
 22            0 
 23            16 
 24            0 
 25            1 
 26            0 
 27            35 
 28            0 
 29            49 
 30            0 

So that is a per Byte dump from obadr. I an see 56 & 16 in there. Seems to be a number out on the left figures for some reason.. Anyway, All those numbers are the same before and after I poke the string data, so im not breaking anything, at least not relating to that.

 

junk = 1 after

 

junk=objc_draw(tree&,ob,3,x&,y&,w&,h&).

&

junk=objc_offset(tree&,ob,x&,y&)

[exxosuk]

X Y W H

328 313 56 16

 

Not sure why I started getting values there all of a suddon, I did reboot steem though just :-\

 

So now I get a overlay again..

 

 

 

[exxosuk]

A quick fix for this is v_bar x,y,x+w,y+h that does work it seems.

 

Thinking about this a little more though, once a GB test is selected, the main window closes anyway, then it does the test, then it draws the whole info window again anyway. So working in individual text boxes and updating them probably isn't actually needed. But at least there is a workaround for this problem in case I do need to update individual text boxes

[gokmase]

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.

[exxosuk]

junk = objc_draw(tree&,0,10,x&,y&,w&,h&) will work to redraw the whole window. I was trying to just refresh individual boxes though. You might have missed my post just that I cheated and used V_bar. I think redrawing the whole screen is probably how it will get done anyway.

 

I'm sure I read somewhere the maximum object depth was 8 though ?

[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.

[exxosuk]

At least I have control of the text now which is awesome, I can start to program the new GUI soon Your help has been invaluable , so thanks for taking the time to help me out

[AtariGeezer]

Which version of HiSoft Basic are you guys working with?

[exxosuk]

V2.1.

[exxosuk]

Well things going well didn't last long The boxes I was outputting to were "strings" but on another form, its "boxtext" and the routine I wrote to output to the "string" boxes doesn't seem to work with the boxtext ones For some odd reason the box just goes blank when I output to it :-\

[exxosuk]

delete this post please

Edited July 10, 2015 by exxosuk

[exxosuk]

Well things going well didn't last long The boxes I was outputting to were "strings" but on another form, its "boxtext" and the routine I wrote to output to the "string" boxes doesn't seem to work with the boxtext ones For some odd reason the box just goes blank when I output to it :-\

 

Still can't figure this out. The X,Y,W,H, all seem fine. I can draw the box ,so tree& is good. Just the actual text doesn't seem to go where its supposed to. It seems to be some 1,000 bytes out on the address :-\

[winterhard]

I know this thread is five years old, so I hope there are still some HiSoft Basic users out there ?

I'm working on a GEM program using the HGT toolkit. Can do menus, windows, objects and the lot. Problem is, all windows open fullsize. I need windows based on screen size (I'm on a 1920x1080 screen). I know how to do it outside of HGT but then I will have to do all the event handling myself. How do I pass the desired window size to, for instance, HGT's OpenTextWindow call? Any sample code would be very welcome.

[winterhard]

1 hour ago, winterhard said:

How do I pass the desired window size to, for instance, HGT's OpenTextWindow call? Any sample code would be very welcome.

I'd better answer my own question. After studying the HGT code I found the relevant HiSoft Basic variables named windx, windy, windw and windh. Not mentioned in the manual, these determine your window size. They are set to your maximum window size by default. Define them as SHARED and use GemAES call wget to find your max window size. (For some reason HBasic's WINDOW GET does not work here.) Use this to adjust the new window to your desired size. Then call HGT's open window call. Like this:

SUB processusermenus (VAL wind,VAL item,VAL title)
    SHARED Finished_Flag,MyWindow,whandle,windx,windy,windw,windh
(...)
      CASE mnopen
        dum = wind_get(whandle,7,windx,windy,windw,windh)   'get screen size
        windw=windh                                         'make the new window square
        whandle=OpenTextWindow("Your window title",win_all-win_info)   
        init
    END SELECT
END SUB

Works for me.

[vargham]

Hello!

I try to compile HGT examples. No luck.

I have a Mega ST with 4 megs of RAM. I use Geneva with NeoDesk. HiSoft BASIC 2.1 works fine until I try to use HGT lib.

Include paths are OK, and I changed the working dir to examples.

The compilation alaways fails with "65 Code generation failed at line x" where x is the last, empty line.

I tried all the examples.