Bug or feature of window.class scroller object?

[blmara]

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

[Rigo]

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

If so, it could speed up a fix.

Simon

[tonyw]

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.

[blmara]

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

[blmara]

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

[Rigo]

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

[blmara]

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

Marko