Executing c command in c

[foleyjo]

Thanks for the advice nicholas though were the 2 links supposed to be to the same site.
I did find that site but I was looking through an example I downloaded from it but the comments were not in English.

I managed to get an image loaded using Dtpic.
It wasn't working earlier but I think I was using an old version of mui as I downloaded the latest from muidev.de and Dtpic worked.

There's also some demos in this version that I didn't have which seem to do things that I need so I can try and learn the code.

[nicholas]

Thanks for the advice nicholas though were the 2 links supposed to be to the same site.
I did find that site but I was looking through an example I downloaded from it but the comments were not in English.

I managed to get an image loaded using Dtpic.
It wasn't working earlier but I think I was using an old version of mui as I downloaded the latest from muidev.de and Dtpic worked.

There's also some demos in this version that I didn't have which seem to do things that I need so I can try and learn the code.

Doh! I posted the wrong first link lol

This is the correct one http://aminet.net/package/dev/c/ACM

These are also handy, they are quite Amiga generic and not so MorphOS specific.

http://library.morph.zone/MorphOS_API_and_Its_Organization
http://library.morph.zone/Exec_Lists
http://library.morph.zone/Taglists

And the bombjack site has PDFs of the RKRM's and almost every Amiga development book ever published.

http://www.bombjack.org/amiga/index.htm

Another handy site for reference

http://amigadev.elowar.com/

Some good articles in this repo too

https://github.com/inrms/guidetoamigacompatibleprogramming/blob/master/README.md

[nicholas]

There's always the excellent Hollywood if you give up on C though.

It's powerful yet simple.

http://hollywood-mal.com/

[foleyjo]

Haha I thought it was strange they both linked to the same page.
. I'll have a read through those other sites tomorrow.

I looked at Hollywood but I read somewhere that it doesn't allow you to launch external programs which is why I avoided it as its something I need.


I've managed to get images changing with a single click now using

Code: [Select]


DoMethod(list, MUIM_Notify, MUIA_List_Active, MUIV_EveryTime,
app, 2,
MUIM_Application_ReturnID, DISPLAY);
   
Where DISPLAY contains a set attributes function on my DtPic object.

So I think I'm going to keep trying for a bit.
I should have enough information now to help me understand what I'm doing

[nicholas]

Haha I thought it was strange they both linked to the same page.
. I'll have a read through those other sites tomorrow.

I looked at Hollywood but I read somewhere that it doesn't allow you to launch external programs which is why I avoided it as its something I need.


I've managed to get images changing with a single click now using

Code: [Select]


DoMethod(list, MUIM_Notify, MUIA_List_Active, MUIV_EveryTime,
app, 2,
MUIM_Application_ReturnID, DISPLAY);
   
Where DISPLAY contains a set attributes function on my DtPic object.

So I think I'm going to keep trying for a bit.
I should have enough information now to help me understand what I'm doing

Excellent! I look forward to seeing your first creation when it's finished.

Hollywood does support launching external programs though btw.

http://www.hollywood-mal.com/docs/html/hollywood/Execute.html

[foleyjo]

Oh no way. If I knew that would have looked into getting hollywood as it looks much easier.

If I get stuck again I'll definitely consider changing to it.
For now I'll just convince myself I made the right choice because I'm learning useful things.

[nicholas]

Oh no way. If I knew that would have looked into getting hollywood as it looks much easier.

If I get stuck again I'll definitely consider changing to it.
For now I'll just convince myself I made the right choice because I'm learning useful things.

You can't go wrong with C, no pain no gain.

[foleyjo]

Me again

Thanks to the advice I received here I have made lots of progress.
I'm still getting things wrong but understand enough to make corrections.
I also understand more about MUI and can work out how to make it do what I want.
I have hit a small stumbling block though.

How do you get the string value from a mui_popstring popup object? So say I wanted the user to select a file and then save the filename to a string what command would I use?

Also what are APTRs and BPTRS, Should I be using them or is it fine to stick with Object * ?
The reason I ask is because the tutorials I used at first had Object * but when I was looking at the mui examples they used APTR. I think APTR looks nicer in the code .

I'm hoping to have something to show soon. (famous last words)

[olsen]

Also what are APTRs and BPTRS, Should I be using them or is it fine to stick with Object * ?

Careful there, this is going to hurt.

You will meet BPTRs almost exclusively in the dos.library functions and the bookeeping data structures which it manages. If a function returns a BPTR, store it as a BPTR, never as an Object pointer or anything else. If a function requires a BPTR as parameter, make sure it came from a variable of type BPTR. Some other operating system functions, which pass parameters to dos.library, also use BPTRs, as well as storing them in the data structures they work with.

You should treat BPTRs as different from any other regular 'C' pointer type you might be familiar with. It helps to keep those variables which hold BPTRs separate from the rest, and always have them use the BPTR type when you declare them.

Why the fuss? A BPTR is not a regular 'C' pointer (the name is an abbreviation for "BCPL pointer", with "BCPL" being the programming language in which dos.library was originally written). You might picture BPTRs as something special which only dos.library knows how to deal with, and the remainder of the operating system has no clue about. If you mix BPTRs up with regular 'C' pointers strange things are guaranteed to happen: crashes are just the beginning, misfortune of all kind will follow you.

You already met the oddly-named APTR (I believe the name may be an abbreviation for "address pointer", but further back in Amiga history, it might have actually stood for "Amiga pointer"). This one is a proper, regular 'C' pointer which holds a memory address. It's just window-dressing for 'void *', which means that it is a pointer which can be assigned to any type of other regular 'C' pointer without causing the 'C' compiler to to warn you that the assignment mixes data types which do not match.

[foleyjo]

So if I understand you right....
I don't need to worry about BPTR unless I'm using a predefined function that takes or returns a BPTR (which will usually be dos functions such as the Lock one I'm using)

APTRs I assume it's more of a preference thing. So I could use char * or APTR when declaring a string pointer and not expect much difference.

[olsen]

So if I understand you right....
I don't need to worry about BPTR unless I'm using a predefined function that takes or returns a BPTR (which will usually be dos functions such as the Lock one I'm using)

Yes, in a nutshell. There always has to be a very good reason for wanting to know more about what a BPTR is and what exactly it points to. You usually do not need to know about these details.

APTRs I assume it's more of a preference thing. So I could use char * or APTR when declaring a string pointer and not expect much difference.

There is more to the APTR type, and how/when to use it.

While the APTR can be assigned to any other pointer type without the 'C' compiler bothering you with warnings, there is a cost: you willl, many times in your 'C' programming career, end up using this special "keep it quiet" propery of the 'void *' pointer (which is what the APTR is) unwisely.

My advice is to never, ever use the APTR or 'void *' pointer in your code if you can help it, and if you do need to use it, you should feel guilty about doing so

The use of this pointer type all too easily obscures the fact that the data pointed to may not be compatible. The compiler will warn you about that, and this is not something you should take lightly by shutting up the warning through an APTR or 'void *' pointer type. What is generally safer is to get rid of that warning by having the pointers being assigned or compared be of compatible types so that the similarity of the data comes out of the data structures as known to the 'C' compiler.

While you do have the choice to use an APTR or 'void *' pointer type in place of more specific pointer types, such as 'char *', it will pay off if you stick to the pointer type which best describes the data being referenced by it. The compiler will help you along by checking for you if the data types are sufficiently similar. You could do all this by yourself, but at some point (programs grow and evolve until you cannot realistically keep track of each part, and every problematic piece of code) this becomes a tedious exercise. Let the machine do that work for you

Side-note: the APTR also exists because of the need to let programmers develop software for the Amiga operating system in assembly language. The data structures you find in 'C' header files for the operating system have counterparts in 68k assembly language header files. Those 68k assembly language header files build the same data structures as found in the corresponding 'C' language header files through the use of macros. In these assembly language macros, "APTR" is a macro which stands for a 32 bit word, which is a pointer of some sort.

[foleyjo]

Thanks Olsen,
I understand what they are now.
I decided against using APTR for the reasons you said. I'm making too many rookie mistakes at the moment and luckily the compiler is catching them. If it didn't I'd have lots more problems.

[guest11527]

I don't need to worry about BPTR unless I'm using a predefined function that takes or returns a BPTR (which will usually be dos functions such as the Lock one I'm using)

Not even then. Or to be more precide: In almost all cases, treat a BPTR as an opaque object. It's what you get out of Lock(), it's what you put into CurrentDir(), don't worry what it means. BPTRs are only for very specific system programming purposes an application developer does not need to worry about.

APTRs I assume it's more of a preference thing.

Neither. As Olaf put it: Always use the fully qualified pointer type. If you have a pointer to an intuition window, that's a "struct Window *", and not an "APTR". If you have a pointer to a character array, that's a "char *".

APTRs are "generic pointers" that do not carry type information. The advantage of a fully qualified pointer is that the compiler will warn you if you try something stupid (like asigning the address of a screen to a pointer of a window), and that's a service a beginner should take advantage of.

So I could use char * or APTR when declaring a string pointer and not expect much difference.

Yes, there is a difference, beyond type checking. Consider this:

Code: [Select]

int primes[] = {2,3,5,7,11};
int *prime_ptr = &primes[0]; /* this is the same as prime_ptr = primes; */
APTR aprime_ptr = &primes[0]; /* OK so far */

printf("%d\n",*prime_ptr); /* Prints 2 */
printf("%d\n",*aprime_ptr); /* compiler error! */

prime_ptr++;  /* advance pointer, points now to "3" instead of "2" */
aprime_ptr++; /* compiler error! */
A generic pointer cannot be dereferenced (what does it point to? You do not know!), and a generic pointer cannot be incremented (what is the address of the next object? You do not know as you do not know what the size of the object is it points to).

HTHH,

Thomas

[olsen]

Thanks Olsen,
I understand what they are now.
I decided against using APTR for the reasons you said. I'm making too many rookie mistakes at the moment and luckily the compiler is catching them. If it didn't I'd have lots more problems.

Funny that you mention lots of problems... One thing which I did not know when I started out in 'C' programming, and which initially gave me cause to worry, was the sheer number of complaints the 'C' compiler would throw at me.

You could make one small mistake, and the compiler would be animated to report errors for code which was perfectly sound.

The trick to deal with this situation is to work through the error messages from the top, one at a time. Ignore the bulk of error messages at the tail end of the compiler output for now.

Why does this happen? The compiler may stumble over code which derails its normal processing operations (could be as little as one character in the wrong place), and in an attempt to get back on track, it skips as much code it cannot make sense of until it looks like it may be safe to process the remainder. This attempt may derail things again, mind you, and then more error messages tumble out.

[foleyjo]

haha tell me about it. Spent a couple of hours last night trying to resolve errors.

I was either being told I needed a ; after an end on one of the lines or would just get 100s of errors.
Turned out the problem was a missing comma further up the page

[foleyjo]

Well Olsen and Thomas thanks to your explanations about APTRs and BPTRs something clicked and I was able to work out how to get the string value from the mui_pop_string.

The talk of pointers, objects and strings made me realise that muia_popstring_string was returning a mui string object and not a string so I retrieved the value in 2 parts.

First I did a get() on the pop object to get the popstring_string object and then did another get on the returned object to get the strings content.

So now I think I understand everything I need to to get my first program completed without having to ask anymore questions.
There's still some stuff that I don't understand such as hooks but I think I'll be able to avoid creating any of my own.

So hopefully I won't be bothering anyone for help and advice till I have something to show.

You guys have helped point me in the right direction and understand so much more than all the guides and tutorials I spent weeks on and the reason why I always return to Amiga.org when I have an Amiga related question.

Cheers