speedbar woes

9 posts / 0 new

Last post

Thu, 2015-09-24 05:02

mritter0

Offline

Last seen: 8 months 2 weeks ago

Joined: 2014-04-21 21:15

speedbar woes

speedbar.gadget v53.12 SDK says v53.29 I have my bar created and added some buttons. Get weird values in Code. AutoDocs says to use int8 for value for AllocSpeedButtonNode(). I have tried that, uint16, uint32, hard coded a number (4). Always returns something like 50450 or 116934, not 0, 1, 2....

IIntuition->GetAttrs(Objects[GAD_BOOKMARKS_SPEEDBAR],
	SPEEDBAR_Selected, &Code,
TAG_DONE);

Same thing.

struct Node *WorkingNode;
IIntuition->GetAttrs(Objects[GAD_BOOKMARKS_SPEEDBAR],
	SPEEDBAR_SelectedNode, &WorkingNode,
TAG_DONE);

Fails to return the node. So can't see SBNA_UserData. When is SBNA_ButtonID coming? Looked around online, can't see anything wrong. Any ideas at what I should be looking at? .....frustrated.......

Thu, 2015-09-24 18:50

tbreeden

Offline

Last seen: 4 years 10 months ago

Joined: 2010-12-09 03:10

Re: speedbar woes

When is the Button ID coming?

Though it seems a bit odd, from the AutoDoc it seems that these two attributes are not supported for OM_GET or OM_Set:

SPEEDBAR_Selected (uint16) Applicability is (OM_NOTIFY) SPEEDBAR_SelectedNode (struct Node *) Applicability is (OM_NOTIFY)

It's also not noted in the AutoDoc, but the SpeedBar example in the SDK gets the gadget ID by calling the WM HandleInput of the enclosing Window class:

                     while ( (result = IIntuition->IDoMethod(objects[OID_MAIN], WM_HANDLEINPUT, &code) ) != WMHI_LASTMSG )
                     {
                           case WMHI_GADGETUP:
                              switch (result & WMHI_GADGETMASK)
                              {
                                 case GID_SPEEDBAR:
                                    IDOS->Printf("Speed Button Selected: %lu\n", code );
                                    switch ((int)code)
                                    {
                                       /* ... */
                                    }

tom

Thu, 2015-09-24 21:06

mritter0

Offline

Last seen: 8 months 2 weeks ago

Joined: 2014-04-21 21:15

Re: speedbar woes

I am doing the Wait() the same way as the demo. The Code is wrong still. Yeah, I saw that they are not OM_GET. I assumed that they would be. Why else would they be there? My Code is uint32. I have tried casting to a few other types but no luck with that. I will keep plugging away at it.............

Fri, 2015-09-25 07:05

mritter0

Offline

Last seen: 8 months 2 weeks ago

Joined: 2014-04-21 21:15

Re: speedbar woes

I figured it out. I have to use IDCMP_IDCMPUPDATE hook and do

if ((WorkingNode=(struct Node *)IUtility->GetTagData(SPEEDBAR_SelectedNode,0,imsg->IAddress)))
{
    ISpeedBar->GetSpeedButtonNodeAttrs(WorkingNode,
        SBNA_UserData,						&Code,
    TAG_DONE);
    HandleBookmarks(Code);
}

The AutoDocs needs some updating.

Fri, 2015-09-25 15:37

(Reply to #4) #5

broadblues

Offline

Last seen: 2 years 12 months ago

Joined: 2012-05-02 21:48

Re: speedbar woes

My Code is uint32. I have tried casting to a few other types but no luck with that.

code is uint16 not a uint32 thus if you pass a pointer to uint32 to the HandleInput metthid things will likely break, as you'll end up with the data in the top half of the uint32 not the lower half where you expect it to be or worse. Whilst you can use the IDCMPHook approach, the autodocs and example are not wrong, the ID *is* returned in the code, same as for may list type objects (tabs, listbrowser etc). You can tell the example is right because it works... if you don't belive the binary with the example was compiled from the example code, compile it yourself :-)

Sat, 2015-09-26 21:06

mritter0

Offline

Last seen: 8 months 2 weeks ago

Joined: 2014-04-21 21:15

Re: speedbar woes

Changed Code from uint32 to uint16. Code value is now "normal", but it is always the value of the speedbar, not which button was pushed. I compiled the demo and it works as expected. That is what is throwing me off. I don't see anything extra or missing that would make the difference. It is probably right in front of my face..... ///////////////////////////////////////// Is there a GCC option to alert of miss-matched types when compiling?

Sat, 2015-09-26 21:27

(Reply to #6) #7

broadblues

Offline

Last seen: 2 years 12 months ago

Joined: 2012-05-02 21:48

Re: speedbar woes

Is there a GCC option to alert of miss-matched types when compiling?

-Wall -Werror -Wwrite-strings -Wno-strict-aliasing Is what I use but it rarely warns about integer size mismatches, (the compiler deals with most of those) though it will warn about sign mismatches in comparisons, and ofcourse pointer to integer mismatch, which would flag up the "code" issue, as uint16 * and uint32 * are not the same. Check for things like GA_RelVerify Did you assign an ID to the individual nodes? etc. If code is returning the speedbar GID are you confusing code and result ? Not I hope usuing the same variable for both?

Sun, 2015-09-27 04:54

mritter0

Offline

Last seen: 8 months 2 weeks ago

Joined: 2014-04-21 21:15

Re: speedbar woes

I have had Code as uint32 from day 1, no problems until now. uint16 is what it should be, changed it. Fine. I use int32/uint32 for almost all number values (width, height, rows, etc.) without problem. This makes passing/getting variables to/from gadgets like listbrowser "easier". Should I be changing all the variable's types to match the tag? LISTBROWSER_SortColumn (int16) LBCIA_Width (int16) Example:

int32 RelEvent, Selected;
 
IIntuition->GetAttrs(Objects[GAD_CONTENT],
	LISTBROWSER_RelEvent,				&RelEvent,
	LISTBROWSER_Selected,				&Selected,
TAG_DONE);

LISTBROWSER_RelEvent is int16. Have to cast it?

Mon, 2015-09-28 16:36

(Reply to #8) #9

broadblues

Offline

Last seen: 2 years 12 months ago

Joined: 2012-05-02 21:48

Re: speedbar woes

I use int32/uint32 for almost all number values (width, height, rows, etc.) without problem. This makes passing/getting variables to/from gadgets like listbrowser "easier". Should I be changing all the variable's types to match the tag?

I don't think there is a one size filts all answer to this. Mostly when passing or receiving integer data via taglists 32bit ints are used, the type then gives a guide for the range of values accepted, you should still pass a "uint32" to SetAttrs or a "uint32 *" to GetAttrs. The latter is more important as the compier usual converts interger type transparently, it can't, ofcourse, convert a pointer type the same way. Care must be used when applying that value to a structure that only expects int16 though. Althought that mostly only applies when working with mixed intuition windows and reaction gadgets rather than window.class windows. Occasionally I've used a intermediate variable to ensure the right value gets through. The code parameter above though is a normal function argument, not a taglist data value so you *must* pass a pointer the right type there.

Search form

User login