Opening RAWBInfo from console (3.2)

[Warty]

I would like to be able to script the opening of the RAWBInfo window for a given file. In the version of RAWBInfo I found on aminet, the AutodocArt has this little quote:

EXTRAS
 The Installer script automatically installs an command called
 WBInfo to your C: drawer. This command allows you to open an
 icon information window from a shell. WBInfo takes the following
 arguments: FILE=DRAWER=OBJECT/M/A,PUBSCREEN/K.
 Where FILE,DRAWER or OBJECT is/are the object(s) to get information
 on and PUBSCREEN the screen where the window should be opened
 (defaults to Workbench).

On my clean 3.2 install, that file is not present in sys:c. even though this aminet version is covered in warnings about 3.5 being required, AS A TEST, I dropped that file into my c: dir, and I can start up RAWBInfo with it. Seems to be stable from workbench.

When I open that from my file manager app, the first pane ("File") is fine, but the 2nd pane ("Icon") will bomb to guru as soon as I click it. Not sure what's going on there. It might not like running from my public screen, dunno.

But main question: what happened to WBInfo? is there any other way to programmatically start up RAWBinfo and pass it a file to display?

[Thomas Richter]

I suggest to look at the rexx interface of the workbench. It should be possible to simulate exactly that.

[Minuous]

The WBInfo command just hasn't been backported from OS4 to OS3.2 yet. I'll sort that out for the next update.

[PeterK]

Originally Posted by Warty

On my clean 3.2 install, that file is not present in sys:c. even though this aminet version is covered in warnings about 3.5 being required, AS A TEST, I dropped that file into my c: dir, and I can start up RAWBInfo with it. Seems to be stable from workbench.

When I open that from my file manager app, the first pane ("File") is fine, but the 2nd pane ("Icon") will bomb to guru as soon as I click it. Not sure what's going on there. It might not like running from my public screen, dunno.

But main question: what happened to WBInfo? is there any other way to programmatically start up RAWBinfo and pass it a file to display?

Did you install that old RAWBInfo v1.18 from Aminet on OS 3.2 over the already supplied RAWBInfo v47? That can, of course, cause trouble, but copying only the file WBInfo from the old version to C: and nothing else may work.

[Warty]

Originally Posted by Thomas Richter

I suggest to look at the rexx interface of the workbench. It should be possible to simulate exactly that.

I don't seem to have retained any REXX knowledge, and looked over an intro REXX thread here today, and literally nothing seemed familiar. I'm sure I'll need to learn some, but hopefully not much.

[Warty]

Originally Posted by Minuous

The WBInfo command just hasn't been backported from OS4 to OS3.2 yet. I'll sort that out for the next update.

Awesome, thanks for adding that to your list.

[Warty]

Originally Posted by PeterK

Did you install that old RAWBInfo v1.18 from Aminet on OS 3.2 over the already supplied RAWBInfo v47? That can, of course, cause trouble, but copying only the file WBInfo from the old version to C: and nothing else may work.

No, I just copied over the WBInfo file, on top of the 3.2 stuff. I'm crazy, but not that crazy.

[PeterK]

Ok, ok, I was just wondering why you wrote:

... this aminet version is covered in warnings about 3.5 being required

You won't get them from copying or executing WBInfo.

And I don't have any problems with that WBInfo on 3.1.4 when I play with it, but didn't test it very long.

Warty, are you using my icon.library? There seems to be something wrong with the selected image of WBStartup/DefIcons.info on your screenshot, and that could cause the crashes. My latest library version delays the uncompressing of the 2. image until you select an icon. But your DefIcons.info file also shows an unusual old Project icon image in WBInfo and says it's a tool (ok, this symbol could mean that the tool replaces project icons). Where does that come from, I've never seen that before. Could you upload that icon?

It looks as if you've added NewIcon images (or only 1 image) to OS 3.2 old icons. Maybe the NewIcon tooltypes of that icon are damaged and when you click onto "Icon" in RAWBInfo it tries to read these damaged tooltypes and crashes.

[Warty]

Originally Posted by PeterK

Ok, ok, I was just wondering why you wrote:

You won't get them from copying or executing WBInfo.

And I don't have any problems with that WBInfo on 3.1.4 when I play with it, but didn't test it very long.

I mentioned the 3.5 thing just because the readme for RAWBInfo (on Aminet) was requiring 3.5 as a requirement, and was clearly written for that, so I didn't really have much expectation that a component of it would work, problem-free, in 3.2.

Originally Posted by PeterK

Warty, are you using my icon.library? There seems to be something wrong with the selected image of WBStartup/DefIcons.info on your screenshot, and that could cause the crashes. My latest library version delays the uncompressing of the 2. image until you select an icon. But your DefIcons.info file also shows an unusual old Project icon image in WBInfo and says it's a tool (ok, this symbol could mean that the tool replaces project icons). Where does that come from, I've never seen that before. Could you upload that icon?

It looks as if you've added NewIcon images (or only 1 image) to OS 3.2 old icons. Maybe the NewIcon tooltypes of that icon are damaged and when you click onto "Icon" in RAWBInfo it tries to read these damaged tooltypes and crashes.

This is a fairly clean 3.2 install, without your icon lib and very little customization in general. Mostly just MuForce/MGA/sashimi/etc.

I'm attaching a snap of my workbench, showing the same set of windows and that defIcons .info open in RAWBInfo.

The above screenshot is from my file manager, and the icons are handled very differently. (there IS something wrong with that .info icon: the "transparent" color is wrong, so the upper right corner looks wrong when highlighted; icon # 45 out of 4500 that needs creating/fixing). Basically, it uses file extensions and mime types to assign icons, without modifying/changing the icons in the .info files. If I get everything done on my to-do list (5% chance of that happening on any given hobby project of mine), you'll be able to swap themes at-a-click, including colors and icons; and will support 32/16 OR 64/32 OR 128/64 ("icon view"/"list view" sizes) icons sizes for folks running huge screen RTG setups. And some other cool stuff, but who knows what reality will have to say about it...

[PeterK]

Oh, that sounds great! I didn't expect that you are working on a new project for changing icon images on the fly. I hope you will have and get enough motivation to finish it successfully as intended.

Then it probably has nothing to do with broken NewIcon tooltypes, but I'm still not sure if WBInfo is responsible for the crashes. I think you will find it out.

[Warty]

Originally Posted by PeterK

Oh, that sounds great! I didn't expect that you are working on a new project for changing icon images on the fly. I hope you will have and get enough motivation to finish it successfully as intended.

arf! that's the heart of the problem indeed. So far, so good though... (and that includes walking away in the middle and working on a serial-syncing program for retro-to-modern computers). Long ways to go though...

Originally Posted by PeterK

Then it probably has nothing to do with broken NewIcon tooltypes, but I'm still not sure if WBInfo is responsible for the crashes. I think you will find it out.

The possibility that something is incompatible with the 3.5 WBINfo program is on par with a wish/dream/prayer. I may not know WHAT is at fault, but I have a pretty good idea WHO is at fault.

[idrougge]

AFAIK a call to open the info window was the single public function in workbench.library as far back as OS 3.1, so there should be several tools for accomplishing that.

[Warty]

Originally Posted by idrougge

AFAIK a call to open the info window was the single public function in workbench.library as far back as OS 3.1, so there should be several tools for accomplishing that.

Doh. It's right there:

workbench.library/WBInfo                             workbench.library/WBInfo

   NAME
	WBInfo - Bring up the Information requester                     (V39)

   SYNOPSIS
	worked = WBInfo(lock, name, screen)
	d0              a0    a1    a2

	ULONG WBInfo(BPTR, STRPTR, struct Screen *);

   FUNCTION
	This is the LVO that Workbench calls to bring up the Icon Information
	requester.  External applications may also call this requester.
	In addition, if someone were to wish to replace this requester
	with another one, they could do so via a SetFunction.

   INPUTS
	lock   - A lock on the parent directory
	name   - The name of the icon contained within above directory
	screen - A screen pointer on which the requester is to show up

   RESULTS
	worked - Returns TRUE if the requester came up, FALSE if it did not.

   NOTE
	Note that this LVO may be called many times by different tasks
	before other calls return.  Thus, the code must be 100% re-entrant.

   SEE ALSO
	icon.library

Thanks, I'll check that out at next opportunity.

[Warty]

I actually found a gap between the auto docs and the prototype. Autodoc says this returns a boolean, but clib protos say it returns void.

This is the auto doc in the 3.2r3 NDK:

workbench.library/WBInfo workbench.library/WBInfo

NAME
WBInfo - Bring up the Information requester (V39)

SYNOPSIS
worked = WBInfo(lock, name, screen)
d0 a0 a1 a2

ULONG WBInfo(BPTR, STRPTR, struct Screen *);

FUNCTION
This is the LVO that Workbench calls to bring up the Icon Information
requester. External applications may also call this requester.
In addition, if someone were to wish to replace this requester
with another one, they could do so via a SetFunction.

INPUTS
lock - A lock on the parent directory
name - The name of the icon contained within above directory
screen - A screen pointer on which the requester is to show up

RESULTS
worked - Returns TRUE if the requester came up, FALSE if it did not.

NOTE
Note that this LVO may be called many times by different tasks
before other calls return. Thus, the code must be 100% re-entrant.

SEE ALSO
icon.library

This is the relevant bit from wb_protos.h from same NDK:

VOID WBInfo( BPTR lock, CONST_STRPTR name, struct Screen *screen );

I have a question, too:
- If I run wbinfo from the CLI, e.g., "wbinfo conflicteurope.info" (from WHDload install), the window that opens shows the tools panel populated.
- Same if I select the icon in WB, and do Amiga-I.
- If I call wb library WBInfo(parent_lock, "conflicteurope.info", my_screen) type thing, it opens, but the tools panel is blank.
- If I call wb library WBInfo(parent_lock, "conflicteurope", my_screen) type thing, it opens, and the tools panel is populated. Mind you, there is no file actually named "conflicteurope" in this folder. I've noticed kind of similar behavior before with .info files. Is this just the way it works? As long as there is AN info file, you never pass it its full name, only the name minus ".info"?

[Minuous]

I fixed the return code issue months ago. Hopefully there will be finally be a release of the updated NDK sometime soon.

Regarding the .info extension, yes, it works the way you have surmised.

Great game by the way, have you tried my editor for it? http://amigan.1emu.net/releases/#mce

[Warty]

I actually HAVE downloaded MCE, but sadly I haven't gotten Conflict Europe working yet on my A3000. Retro time is always a question of "should I play this game or should I work on the project?" Most times I work on the project...