Hyperion Entertainment Message Boards

Posted: **Sun Apr 21, 2013 10:05 pm**

Hi,

in my program I use window.class window and the WINDOW_HorizProp & _VertProp scrollers created with tag value 1. I use the following code to adjust the scrollers according to the view size and position:

Code: Select all

void AdjustVProp(struct sdoc *dobj)
{
    LONG DotsPI = dobj->dotsperinch;

    if (dobj->gads[GAD_VPROP])
      {
        IIntuition->SetGadgetAttrs((struct Gadget *)dobj->gads[GAD_VPROP],dobj->win,NULL,
            SCROLLER_Top,dobj->globy / dobj->scrollstepy,
            SCROLLER_Visible,PIX2DPOINT(((struct Gadget *)dobj->gads[GAD_DRAWAREA])->Height) / dobj->scrollstepy,
            SCROLLER_Total,dobj->vtotal / dobj->scrollstepy,
            TAG_DONE);
      }
}

Mostly works ok, but there seems to be a problem, when I pass the following values to the horizontal scroller:

Top 25, visible 50, total 83

Visually the scroller shows as the Top would be 0. When setting different values works as it should, but when going to visible == total and then reusing the values above problem reoccur. Very odd is, that when I changed the order of SetGadgetAttrs() to Visible,Total,Top, the scroller works as it should. Why is this, shouldn't the scroller work regardless of the order of the SetGadgetAttrs() arguments?

Marko

Posted: **Sun Apr 21, 2013 11:19 pm**

Do you have a small example with source that demonstrates the problem?

If so, it could speed up a fix.

Simon

Posted: **Mon Apr 22, 2013 1:00 am**

The gadget works the same way as all other gadgets: it reads your Tag List and obeys each tag in the order it comes to them.

So you must have the tags in the right order. It's a "feature" of all the gadgets.

Posted: **Mon Apr 22, 2013 10:05 pm**

tonyw wrote:The gadget works the same way as all other gadgets: it reads your Tag List and obeys each tag in the order it comes to them.

So you must have the tags in the right order. It's a "feature" of all the gadgets.

So I found the 'right' order of scroller.gadget by accident. It seems not to be documented in the autodocs. And for some reason the failure is not always there. Could the right order of tags to be documented there? Are there some other classes that are very picky about the order?

Marko

Posted: **Mon Apr 22, 2013 10:09 pm**

Rigo wrote:Do you have a small example with source that demonstrates the problem?

If so, it could speed up a fix.

Simon

Code: Select all

#define ALL_REACTION_CLASSES 1
#define ALL_REACTION_MACROS 1
#include <reaction/reaction.h>
#include <intuition/intuition.h>
#include <proto/intuition.h>
#include <proto/dos.h>

Object *vscroller,*hscroller;

int main()
{
	Object *winobj;
	struct Window *win;

    	winobj = WindowObject,
	      	WA_Title, "TestWindow",
	      	WA_Width,800,
	      	WA_Height,600,
	      	WA_ScreenTitle, "Testing",
		WA_SizeGadget, TRUE,
    		WA_DepthGadget, TRUE,
    		WA_CloseGadget, TRUE,
    		WA_DragBar, TRUE,
    		WA_Activate, TRUE,
    		WINDOW_Position, WPOS_CENTERSCREEN,
    		WINDOW_IconifyGadget,TRUE,
        	WA_IDCMP,IDCMP_GADGETDOWN|IDCMP_MOUSEMOVE|IDCMP_NEWSIZE|IDCMP_RAWKEY|IDCMP_EXTENDEDMOUSE,
    		WINDOW_HorizProp,1,
    		WINDOW_VertProp,1,
    		WINDOW_IDCMPHookBits,IDCMP_IDCMPUPDATE|IDCMP_GADGETDOWN|IDCMP_RAWKEY|IDCMP_EXTENDEDMOUSE,
	      	WINDOW_Layout,VLayoutObject,
	        	LAYOUT_DeferLayout,TRUE,
           		LAYOUT_AddChild, SpaceObject,SpaceEnd,
          	LayoutEnd,
    	TAG_DONE);

	if (winobj)
	{
		if (win = RA_OpenWindow(winobj))
		{
			IIntuition->GetAttr(WINDOW_VertObject,winobj,(ULONG *)&vscroller);
            		IIntuition->GetAttr(WINDOW_HorizObject,winobj,(ULONG *)&hscroller);
			IIntuition->SetGadgetAttrs((struct Gadget *)hscroller,win,NULL,
				SCROLLER_Top,25,
				SCROLLER_Visible,50,
				SCROLLER_Total,83,
				TAG_DONE);
			IDOS->Delay(200);
		}
		IIntuition->DisposeObject(winobj);
	}
	return(0);
}

This scroller is not at position 25 but at position 0.

Marko

Posted: **Mon Apr 22, 2013 10:39 pm**

OK, it looks like setting SCROLLER_Top first is checking if something has already been changed, whereas setting the Visible attribute first makes the change required in the Top attribute check.

I've no idea why this was done this way, and will take a bit of investigation, but in the meantime, move the SCROLLR_Top attribute to the second value passed, and everything should work as you expect.

Thanks for the report and the example code, it makes our job much easier when specific circumstances such as this are encountered.

[later]

This should be fixed in 53.14 released for internal beta-testing.

Simon

Posted: **Tue Apr 23, 2013 10:55 pm**

Thanks Rigo, changed my code but also waiting for the fix!

Marko

Hyperion Entertainment Message Boards

Bug or feature of window.class scroller object?

Bug or feature of window.class scroller object?

Re: Bug or feature of window.class scroller object?

Re: Bug or feature of window.class scroller object?

Re: Bug or feature of window.class scroller object?

Re: Bug or feature of window.class scroller object?

Re: Bug or feature of window.class scroller object?

Re: Bug or feature of window.class scroller object?