GetApplicationAttrs()

19 posts / 0 new

Last post

Tue, 2015-09-08 05:39

mritter0

Offline

Last seen: 2 years 5 months ago

Joined: 2014-04-21 21:15

GetApplicationAttrs()

I have registered my application:

appID=IApplication->RegisterApplication(PROJECT_NAME2,
	REGAPP_URLIdentifier,		"projectname.com",
	REGAPP_Description,		"My program description",
	REGAPP_AppIconInfo,		AppIconInfo,
	REGAPP_FileName,		ProgramComplete,
	REGAPP_HasIconifyFeature,	TRUE,
	REGAPP_HasPrefsWindow,		TRUE,
	REGAPP_CanCreateNewDocs,	TRUE,
TAG_END);

Then I want to get the identifier to show to users so they can find my app (there may be multiple copies running):

char appIDName[256];
 
IApplication->GetApplicationAttrs(appID,
	APPATTR_Port,		&AppLibPort,
	APPATTR_AppIdentifier,	&appIDName,
TAG_DONE);

I only get garbage returned. What is the correct way to do this? Do I need to specify more tags in RegisterApplication()?

Tue, 2015-09-08 08:12

zzd10h

Offline

Last seen: 7 years 2 weeks ago

Joined: 2012-08-24 20:56

Re: GetApplicationAttrs()

What do you have in PROJECT_NAME2 ?

Is SysMon "Applications" tab detect your program and display a correct Application name ?

Tue, 2015-09-08 10:25

salass00

Offline

Last seen: 6 months 1 week ago

Joined: 2011-02-03 11:27

Re: GetApplicationAttrs()

Change the code to:

STRPTR appIDName;
 
IApplication->GetApplicationAttrs(appID,
    APPATTR_Port,		&AppLibPort,
    APPATTR_AppIdentifier,	&appIDName,
    TAG_DONE);

and it will work.

BTW the attributes that return a string create a copy using AllocVecTags() and returns that to the application. As far as I can tell the application is supposed to call FreeVec() to free the string when done with it although there is no mention of this anywhere in the autodoc.

Tue, 2015-09-08 18:54

mritter0

Offline

Last seen: 2 years 5 months ago

Joined: 2014-04-21 21:15

Re: GetApplicationAttrs()

That works. Thanks.

Kind of tied to it, I can't get any images to display in the Ringhio messages.

Result=IApplication->Notify(appID,
	APPNOTIFY_Title,			Title,
	APPNOTIFY_Text,				Text,
	APPNOTIFY_PubScreenName,	ScreenName,
	APPNOTIFY_ImageFile,		ImageFile,		// 32x32 max
	APPNOTIFY_BackMsg,			BackMsg,
TAG_DONE);

I have tried it with a few different images, nothing.

application.library v53.12.

Thu, 2015-09-10 00:43

(Reply to #4) #5

jabirulo

Offline

Last seen: 2 weeks 6 days ago

Joined: 2013-05-30 00:53

Re: GetApplicationAttrs()

Even if you try hardocded imagefile (APPNOTIFY_ImageFile, "TBImages:caltoday")?

IApplication->Notify(dd->appID,
   APPNOTIFY_Title,         "DateTime Docky",
   APPNOTIFY_Update,        TRUE,
   //APPNOTIFY_Pri,           0,
   APPNOTIFY_PubScreenName, "FRONT",
   APPNOTIFY_ImageFile,     "TBImages:caltoday",
   //APPNOTIFY_CloseOnDC,     TRUE,
   APPNOTIFY_Text,          GetString(&li, MSG_RINGHIO_NOTIFICATION, db),
TAG_DONE);

AOS4.1/SAM460ex/PPC460EX-1155MHZ/2048MB/RadeonHD6570/SSD120GB/DVDRW :-P

Thu, 2015-09-10 04:03

mritter0

Offline

Last seen: 2 years 5 months ago

Joined: 2014-04-21 21:15

Re: GetApplicationAttrs()

Yep.

I know. Totally throwing me off. Something so simple is not working.

Thu, 2015-09-10 12:06

tboeckel

Offline

Last seen: 4 years 5 months ago

Joined: 2011-09-13 12:32

Re: GetApplicationAttrs()

This is the code section we are using in YAM and it is definitely working:
YAMApplication.c line 1343

Thu, 2015-09-10 20:13

mritter0

Offline

Last seen: 2 years 5 months ago

Joined: 2014-04-21 21:15

Re: GetApplicationAttrs()

I figured out my problem.

PROGDIR:Images/myimage.png

does not work. Ringhio doesn't know what PROGDIR: is, just my program. Have to use full path:

DH2:MyProgram/Images/myimage.png

Fri, 2015-09-11 15:28

(Reply to #8) #9

trixie

Offline

Last seen: 6 months 3 weeks ago

Joined: 2011-02-03 13:58

Re: GetApplicationAttrs()

@mritter0

Sorry I didn't spot this thread earlier. I think it was kas1e who reported this problem about a year ago - Ringhio (or more likely, the Application Library) cannot resolve PROGDIR: correctly. Which is quite funny, as the NotifyA() example in the Application Library autodoc does indeed use PROGDIR: in the APPNOTIFY_ImageFile tag.

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

Fri, 2015-09-11 15:29

(Reply to #9) #10

salass00

Offline

Last seen: 6 months 1 week ago

Joined: 2011-02-03 11:27

Re: GetApplicationAttrs()

Ringhio doesn't know what PROGDIR: is

More like Ringhio message server has a different PROGDIR: from your program.

Fri, 2015-09-11 15:42

(Reply to #10) #11

trixie

Offline

Last seen: 6 months 3 weeks ago

Joined: 2011-02-03 13:58

Re: GetApplicationAttrs()

@salass00

More like Ringhio message server has a different PROGDIR: from your program.

It would be worth checking whether the Application Library (provided that during registration the app gives its full path via REGAPP_WBStartup, REGAPP_FileLock or REGAPP_FileName) sends this path to the Ringhio server in order to correctly resolve the application's PROGDIR: instead of using Ringhio's.

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

Sat, 2015-09-12 19:14

(Reply to #11) #12

xenic

Offline

Last seen: 2 years 7 months ago

Joined: 2011-05-07 04:52

Re: GetApplicationAttrs()

@trixie
Since PROGDIR: gets resolved to the current processes' program directory by AmigaDOS when it is used in an AmigaDOS function call, you cannot use a path containing PROGDIR: in a function call to another library or in a message to another process. Some time ago a similar problem was reported at an Amiga WEB site when sending a path name to ARexx. I think the bug is in the autodoc and not in Application library itself.

P.S. Are you actually still using update 6 as indicated in your tag line?

X1000 - OS 4.1FE

Sun, 2015-09-13 08:54

(Reply to #12) #13

trixie

Offline

Last seen: 6 months 3 weeks ago

Joined: 2011-02-03 13:58

Re: GetApplicationAttrs()

@xenic

you cannot use a path containing PROGDIR: in a function call to another library or in a message to another process

I know. My point was: if the application actually bothers to register with a full path, why doesn't the Application Library (upon receiving "PROGDIR:" in a tag like APPNOTIFY_ImageFile) replace "PROGDIR:" with the application path?

Are you actually still using update 6 as indicated in your tag line?

Yes. I've bought the Final Edition of course but I haven't got to instaling it yet. I moved house in the summer and my Sam is still packed in a box someplace around :)

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

Sun, 2015-09-13 19:27

(Reply to #13) #14

xenic

Offline

Last seen: 2 years 7 months ago

Joined: 2011-05-07 04:52

Re: GetApplicationAttrs()

@trixie

I know. My point was: if the application actually bothers to register with a full path, why doesn't the Application Library (upon receiving "PROGDIR:" in a tag like APPNOTIFY_ImageFile) replace "PROGDIR:" with the application path?

While it might be possible for Application Library to scan paths for "PROGDIR:" and replace it with the path used in registration, would it be a good idea for Application Library to be an exception to the rule of not passing "PROGDIR:" to a library or another process? In addition, if "PROGDIR:" is accepted in the path to an image one might assume that "PROGDIR:" could be use for the path in initial registration. My preference would be for Application Library to flag the use of "PROGDIR:" as an error and post an error mesage; which would be more consistant with the standard use of "PROGDIR:".

P.S. While checking the Application library autodocs I noticed that the tag description for FINDAPP_Filename under FindApplication states: "If this tag is specified, FINDAPP_Filename is ignored." I think it's the first Tag I've seen whose sole purpose is to ignore itself :-)

X1000 - OS 4.1FE

Sun, 2015-09-13 21:32

(Reply to #14) #15

trixie

Offline

Last seen: 6 months 3 weeks ago

Joined: 2011-02-03 13:58

Re: GetApplicationAttrs()

@xenic

would it be a good idea for Application Library to be an exception to the rule of not passing "PROGDIR:" to a library or another process?

So how come the Bitmap Image class can use "PROGDIR:" in BITMAP_SourceFile, if the class is in fact a library? Didn't you say there was a rule? :-)

Some applications will probably come with an "Images" drawer containing graphic data the program uses. If the program normally refers to "PROGDIR:Images/" to access its image files, and this path will suddenly not work when NotifyA() called by the same program wants to display an image, then we have something I'd call inconsistency. Go tell the programmer "you can use PROGDIR: in Bitmap Class but not in Application Library stuff", I'm sure there will be some raised eyebrows.

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

Sun, 2015-09-13 22:23

(Reply to #15) #16

xenic

Offline

Last seen: 2 years 7 months ago

Joined: 2011-05-07 04:52

Re: GetApplicationAttrs()

@trixie
Perhaps you're right. If the library function call is executed within the programs process context, then the PROGDIR: would be resolved. I suppose that the problem occurs if the library function passes PROGDIR: to a handler or another process in a message etc. Maybe I'm wrong about libraries in general and Application Library should be resolving PROGDIR: before it's sent to Ringhio. This certainly wouldn't be the first time I've been wrong about something :-)

X1000 - OS 4.1FE

Tue, 2015-09-15 16:29

(Reply to #16) #17

broadblues

Offline

Last seen: 4 years 9 months ago

Joined: 2012-05-02 21:48

Re: GetApplicationAttrs()

Some applications will probably come with an "Images" drawer containing graphic data the program uses. If the program normally refers to "PROGDIR:Images/" to access its image files, and this path will suddenly not work when NotifyA() called by the same program wants to display an image, then we have something I'd call inconsistency.

It's only inconsistent when viewed through the narrow keyhole of that API. In the wider OS it's completely inconsistent.

PROGDIR: is always interpreted by dos.library in the context of the actual program , so you can't use it in an interpreted script for example (unless you really mean to access the script interpreters progdir: ) . Making anything try to second guess progdir: wil result in muddy the waters, which are quite clear if you stand back far enough, even if there appears to be a few eddies when look close up at an API.

The autodoc is a bad example and should be updated.

If a programmer wants to use progdir: as a simple way of finding their resources and they need to pass those resources onto another application, then they should use Lock("PROGDIR:") and use that lock in GetNameFromLock();

[edit]
Just to create an eddy for the sake of fun, you can use it a blender script, because blender has python embedded rather than using the external one, but you can't use it in blender ARexx script

Another case of 'inconsistancy' caused by looking too close up to see the pattern
[/edit]

Wed, 2015-09-16 10:51

(Reply to #17) #18

trixie

Offline

Last seen: 6 months 3 weeks ago

Joined: 2011-02-03 13:58

Re: GetApplicationAttrs()

@broadblues

It's only inconsistent when viewed through the narrow keyhole of that API. In the wider OS it's completely inconsistent.

"Completely consistent" you mean?

AmigaOne X5000-020 / 2GB RAM / Sapphire Pulse Radeon RX 560 / AmigaOS 4.1 Final Edition Update 2

Wed, 2015-09-16 13:44

(Reply to #18) #19

broadblues

Offline

Last seen: 4 years 9 months ago

Joined: 2012-05-02 21:48

Re: GetApplicationAttrs()

Ooop yes "Completely consistent"

Search form

User login