Assignment 2 Question 3

A very silly question:
In the Book class, did you guys use an enum for the categories? Do we have to?
I tried it, working from the example in the book, but in the end it became such a kludge that I threw it out.

Thanks in advance!

JB

Nope, I used an integer. From my C# knowledge, not sure about C++ but enums are basically named integers.

Ja, enums are named integers, but you define an enum as a type.
In the end, early morning, my patience was running then, so I decided "Screw it, make it a string like the rest and be done with it." It makes it so much easier.

Thanks!

JB

Just a question with the getters.

Did you use:

type getSomething() const {
return property.("YourPropName".toString();
}

or did you use:
type getSomething() const {
return m_Something;
}

The reason I ask is the example in the book shows using the setters in the standard way, but the accessor uses the property, however they also mention that the accessorts are used as per normal.

esckay

I used
type getSomething() const {
return m_Something;
}

working from the example in the book.
I must have missed the paragraph where they discussed the
property.("PropName".toString() way...

Cheers,
JB

I left the category as a string field. Is that incorrect?

sanjivdo,

I hope not! That's what I did as well. Sorry if I did not express myself very clearly.

Regards,
JB

I have another question here. I am attempting to use the category as emunerated values, but I am getting a segmentation fault error.

I used the code on page 349 of the text book and I receive the error on the following line:
m_Type = static_cast<CustPropsType>(menum.ketToValue(ntyp));

Can anyone help ?

Well, more specifically:

I am attempting the use of enumerated values for the categories, but I am receiving a segmentation fault error. My code looks exactly like the code on page 349 of the text book, except that I substituted it with my own variable names.

I receive the segmentation fault in the following line:
m_Type = static_cast<CustPropsType>(menum.keyToValue(ntyp));

More specifically, the segmentation fault occurs in the keyToValue method on the following statement:
while (*s && *s != ':' ++s;

The first time that I call the void CustProps::setType(QString newType) method, it works, but it seems the second/third time I call the method I receive the segmentation fault. Sometimes it fails on the second call and sometimes on the third. I can't find a clear pattern why.

The void CustProps::setType(CustPropsType newType) method works everytime.

Can someone please help me out here. I could not find anything on the net that was of any help so far.

Anyone ? Please ?

Why don't you drop the enumerated value and use a string or an integer?

I suppose, I just wanted it to work with the enumerated value.

I have however given up on passing a string to the enumerated value. I now just use enumnerated values for Category.

Thanks

Hi, Dunno if this is the right spot to post, but suppose there's no better.

Having abit of trouble with part 2 of question 3, what exactly are we supposed to do, I mean just letting BookList inhereit from Book makes it a class that can Have Book objects as children. Do we need to add in extra methods for adding the book objects and/or any other methods.

Thanks

One other thing - maybe a bit lame to most - but trying to compile the example on pg 351 - the testcustomerprops.cpp says that it cannot find "assertequals.h" - i've looked but cannot find.

This book has heaps of stuff the does not compile straight away - a lot of tweaking needed.

Anyone else find it so?

That assertequals.h is probably part of Ezust's libs. Yes, the book's code needs to be tweaked. I consider this a great learning curve. I've just started Q3. It seems to deal with MOC macros, hence the QObject (ahem). I must now just figure out how that silly stuff works (between TB and assistant). I still think that Java does all of this better

Fo sho!

The text is poor imho. No worries though - we push on!

Here's my dumb question:
3.1 says: Write a class Book (derived from QObject) with appropriate attributes to describe a book.
3.2 says: Create another class named BookList where Book objects will be children of BookList.
Does this mean I must break my Book class and let it inherit from BookList? That means that Book : QObject changes to Book : Booklist and I have to introduce BookList : QObject? Then I have to move all the Q_PROPERTY from Book to BookList, because Q_PROPERTY must use QObject and the Q_OBJECT macro?
Could someone clear this up please? I'm confused (and reluctant).

You can create the BookList class that iterates through all its children (or what not).

So:
BookList *list = new BookList;

Book *book1 = new Book(list, "Book Title";
(assuming your book constructor is Book(QObject *parent, QString title))

makes book1 a child of list.

So, as far as my understanding goes, Book and BookList are completely separate classes.

Am I helping?

JB

Neat trick in passing between classes. Ok, so BookList will contain Book. I think I misinterpreted the jargon here. I understood that if a class was a child of another class, inheritance was implied. <phew>. Thanks, Johan

NP

Sorry JB, I didn't quite get your code. I've been trying this as a function of BookList...

void BookList::addToList(Book b){
list<Book> *BList;
BList.push_back(b);
}

What's wrong here? I've included the <LIST>, compiler says push_back has not been declared.

I'm missing something here for sure - anyone?
Thanks in advance!

Ryan, use QList<T>, and then QList.append to add an item to the list

Thanks bassman - something else is stuffed up here though

I'll sleep on it, see what happens tomorrow night

One thing I would change would be to rather add Book pointers to the list. So your declaration would be QList<Book*> BList;

Ryan Botha Wrote:
-------------------------------------------------------
> Sorry JB, I didn't quite get your code. I've been
> trying this as a function of BookList...
>
> void BookList::addToList(Book b){
> list *BList;
> BList.push_back(b);
> }
>
> What's wrong here? I've included the , compiler
> says push_back has not been declared.
>
> I'm missing something here for sure - anyone?
> Thanks in advance!

Ryan,

I didn't explicitly add a function to add a book to a list - I add my books to a list when I create them - Book *book1(list, "book title" adds book1 to list.

If I remember correctly, if you want to have a function that adds a book to a list, you have to much around with QObject.setParent or QObject.setChild or something to that effect. Qt Assistant is your friend, I don't have it installed at work unfortunately.

Hope this helps.
JB

*Edit:
So instead of making your own list and using it, you use the list of children that QObject maintains.

Then in your parent class (BookList) you manipulate the children with something like
QList<Book*> list;
list = findChildren<Book*>();
foreach (Book *current, list)
{
// Insert your code here.
}

Just thought I'd clear that up.
JB

Great, thank you JB.

These Qt macros really suck! I had code working, messed around with it, changed it back, now it doesn't work. Could someone please look at the code and suggest where I went wrong and how to fix it plz?

//from .h
public:
	Book(QObject *parent, const QString name);

//from .cpp
Book::Book(QObject *parent = 0, const QString name = QString()) : QObject(parent){
	setObjectName(name);
}

//from main
	Book *book1 = new Book();

//src/main.cpp:8: error: no matching function for call to ‘Book::Book()’

Funny that it worked with the empty constructors the first time. ya rly.

Book *book1; gives the following error

[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb70c2720 (LWP 13420)]
0xb78166f4 in QObject::setProperty () from /usr/lib/libQtCore.so.4

Rick,

Did you put a ; after the last } in the header file?
I seem to remember a similar error message when I forgot to do that.

JB

yes