litwindow-users — how to use the litwindow library

RE: [litwindow-users] Now implemented : Re: <map> as container

[yrs90 <yr...@ya...>]

> I am about to commit changes that allow a map<> to be used with 
> container adapters.

I tried the updated code you submitted. (In fact I tried a messier version
of the same thing at one point yesterday using <pair> rather than
value_type.) However even using your updates, I get an error from RapidUI.
Now I realize I might have been focusing on the container when the problem
is now my rule.

I have a rule which states:

RULE("xrcList", make_expr<accessor>("m_MapOfItems"))

When I run, I get the assertion during startup:
	std::runtime_error: from_accessor method not implemented

The assertion appears to be correct.  The from_accessor looks like it is not
implemented when <pair> is declared ...ADAPTER_NO_COPY.  However, without
NO_COPY there will be problems because of operator=.  Why doesn't it want to
play with the list?

Regards,
Joel



---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] unittests

[yrs90 <yr...@ya...>]

I ran the unittests.  I got the following output.  The couple of exceptions
I looked at appear to be consistent with a successful test.

unittest_md.exe
.........................................


OK (41 tests)


<RETURN> to continue

--------------- lw_err ---------------
lwbase_error exception is not a container
lwbase_error exception is not a container
lwbase_error exception invalid from_string<int> input. not a number.
lwbase_error exception type mismatch
lwbase_error exception no such property
lwbase_error exception converter<Fix1>::to_string method not implemented
lwbase_error exception value conflict
lwbase_error exception value conflict
lwbase_error exception Variable fixValue1 has type Fix1 but type int
expected.
lwbase_error exception Variable noSuchVariable not found



---
[This E-mail scanned for viruses by Declude Virus]

RE: [litwindow-users] Re: <map> as container

[yrs90 <yr...@ya...>]

> Is the sort order an inherent attribute of the 
> collection? Or is the sort order just a 'view' to the collection, 
> imposed by the user.... So, should sorting be part of the container 
> or not?

I had assumed that sort order should be part of the view rather than part of
the container.  Multiple views of data are not uncommon.  Multiple views
probably require that sort order be independent of the container.

> Iterators otoh will be short-lived objects used to access and iterate 
> the container. Their sort order can be changed without changing the 
> actual sort order of the underlying container.

This is an interesting perspective.  I had assumed that sorting would be
handled by the view itself rather than by an iterator.  Is there a way to
provide sorted iterators efficiently?

> Bookmarks otoh would be a much higher-level abstraction and should be 
> unique for every object inside the container.
>
> My current thinking is having bookmark as a unique 'address' of an 
> element in a container. Bookmarks should remain valid for all operations.
> ...
> A bookmark is just that, a bookmark. Most database engines support 
> bookmarks for rows inside a table. A bookmark remains valid as long as 
> the row exists, regardless of other insertion/deletion operations.

This sounds a lot like the iterator for a list or map.

> This high-level container might even contain more than one 'index'.

I don't see why it is desirable to have more than one index to a given
container element.  Well, that is unless you mean to have the index not only
indicate the item, but also the particular sorting that was used.  But that
seems unnecessary since element ordering is available from the view (or
through a sortable iterator).


> Idea 2:
> Insertion / deletion is never done by the container itself, but by some 
> control that owns the container.
>
> This would make the insertion/deletion easier, but you couldn't bind 
> more than one control to a container.

Restricting to a single association between a control and a container is too
constraining for a general framework, I think.  Although, so long as (a)
only one control could access a given container at any given time and (b) a
container could notify all bound controls when change had occurred, then I
think it would work for multiple controls bound to a single container too.

> Idea 1:
> Insertion / deletion is being handled by the container itself. 
> Interested objects are being notified.

The only troublesome part of this is that it takes a bit of work for a
control to gain access to its bound container.  I expect the access
mechanism could hidden, which would make this the more versatile approach.
For one thing, a deletion from a view might be achieved by setting a
container element attribute to "hidden".


Best regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

RE: [litwindow-users] Now implemented : Re: <map> as container

[yrs90 <yr...@ya...>]

Many thanks!  My attempt has been stymied the proper form of the <pair>
declaration, but I see you've addressed that.  I'll take a look.

Best regards,
Joel 

-----Original Message-----
Hi all,

I am about to commit changes that allow a map<> to be used with 
container adapters.

In order to use it you must first use a typedef

typedef std::map<std::string, int> the_map;

then define an aggregate adapter for the pair<string, int>

// note: the LWL_.... macros will replace the BEGIN_.... macros
// LWL_ stands for Lit Window Library. I've lifted this scheme
// from the boost library.

LWL_BEGIN_AGGREGATE_NO_COPY(the_map::value_type)
     PROP(first)
     PROP(second)
LWL_END_AGGREGATE()

and finally use IMPLEMENT_ADAPTER_CONTAINER to make the adapter known to 
the system.

IMPLEMENT_ADAPTER_CONTAINER(the_map)




Have a look at unittests\containertests.cpp to see how it is used.

Expect commit within 30 minutes.

Regards

Hajo


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Now implemented : Re: <map> as container

[Hajo K. <mai...@ha...>]

Hi all,

I am about to commit changes that allow a map<> to be used with 
container adapters.

In order to use it you must first use a typedef

typedef std::map<std::string, int> the_map;

then define an aggregate adapter for the pair<string, int>

// note: the LWL_.... macros will replace the BEGIN_.... macros
// LWL_ stands for Lit Window Library. I've lifted this scheme
// from the boost library.

LWL_BEGIN_AGGREGATE_NO_COPY(the_map::value_type)
     PROP(first)
     PROP(second)
LWL_END_AGGREGATE()

and finally use IMPLEMENT_ADAPTER_CONTAINER to make the adapter known to 
the system.

IMPLEMENT_ADAPTER_CONTAINER(the_map)




Have a look at unittests\containertests.cpp to see how it is used.

Expect commit within 30 minutes.

Regards

Hajo

[litwindow-users] Re: <map> as container

[Hajo K. <mai...@ha...>]

I forgot to add:

list<> already works, so if you need a container that does not 
invalidate the iterators after an insert/delete operation, you could use 
list.

Hajo

[litwindow-users] Re: <map> as container

[Hajo K. <mai...@ha...>]

yrs90 wrote:
> I have been pondering <map> containers again.
> 
> The reason that <map> could not be used as a container was that it didn't
> have a way to be bookmarked like a vector, is that right?  I'm not sure I
> understand the limitation.  It seems that there are at least two possible
> ways of dealing with bookmarks using a <map>.

The bookmarks referred to in the vision document do not exist yet. Also 
the discussion in the vision document is at a very high level of 
abstraction. map<> are not suitable for the high-level container concept 
because it does not preserve a sorting order. map<> always impose their 
own sorting order.

This high-level container might even contain more than one 'index'. 
Implementation wise it could be an stl vector that maintains the custom 
sort order plus several other vectors, each representing a different 
'index' that contain pointers to the original data. Sorting offers a 
subtle design problem. Is the sort order an inherent attribute of the 
collection? Or is the sort order just a 'view' to the collection, 
imposed by the user. This problem becomes clear when you think of a 
multi-user scenario. Suppose you had a list of addresses. My preferred 
sort order will be different from your sort order, so 'sort' is not an 
attribute of the collection. So, should sorting be part of the container 
or not?


The current reason why map<> cannot be used with 
IMPLEMENT_CONTAINER_ADAPTER is much simpler. I haven't had the time to 
write a map container adapter. The only container adapter that exists so 
far is the vector container adapter.

> If the bookmarks are refreshed when a NotifyChanged() is received, the
> existing implementation of indexing off the begin() iterator looks
> sufficient.  As it stands now, when a new data element is inserted or
> deleted, the entire view is repopulated, so the index can be refreshed with
> the updated ordering.
> 
> If the bookmark needs to persist in the face of insertions and deletions,
> the iterator itself could be used as the bookmark.  <map> has the nice
> feature of not invalidating the iterators when an element is inserted or
> deleted (other than the deleted element).  This is less volatile than a
> <vector>.

Yes, true.

Currently, NotifyChanged works with the entire container only. What 
would be needed is NotifyInserted and NotifyDeleted for containers.

This area of the Lit Window Library is not implemented yet.

Here is what I think needs to be done:

Idea 1:
Insertion / deletion is being handled by the container itself. 
Interested objects are being notified.

NotifyInserted should notify any interested object that an insertion has 
occurred in a container. It should also include a 'bookmark' as to where 
this insertion has occurred. The bookmark should point to the object 
immediately behind the insertion. Bookmarks in this sense are an 
abstract concept of iterators. ODBC bookmarks will look entirely 
different than STL iterators, so 'bookmark' is a high level abstraction, 
much as the container adapter is a high level abstraction to a concrete 
container.

NotifyDeleted should notify any interested object that a deletion has 
occurred.
Perhaps the notification should also include
NotifyInserting - NotifyDeleting
events that are being sent just before the insertion/deletion is being made.

Idea 2:
Insertion / deletion is never done by the container itself, but by some 
control that owns the container.

This would make the insertion/deletion easier, but you couldn't bind 
more than one control to a container.


My current advice is not to rely on the library for this case. There 
still needs some conceptual work to be done and the container 
abstraction needs to be enhanced for this in order to work.

If you need a map, you could use a map as an index in addition to the 
vector. Or write the container adapter for a map, which is not very 
difficult. IMPLEMENT_CONTAINER_ADAPTER will then work for map<> as well.

To avoid repopulating the entire view every time a single element is 
inserted or removed from the view, you will have to write your own 
notification mechanism at this time. The problem is that you can 
currently access elements inside a container only sequentially.




That is if you have a

litwindow::container mycontainer=myaccessor.get_container();

and want to access a specific (say the 12th) element, you can only use

size_t element_index=12;
container::iterator i;
while (element_index--)
   ++i;

There is no [] operator yet. This would be equivalent to a 'seek' 
operation. What is needed is something along the lines of

container::bookmark bmark;
container my_container=my_accessor.get_container();
container::iterator i=my_container.seek(bmark);

which would return a container iterator pointing to the element at 'bmark'.

bmark would either have to be valid even after insert/delete operations 
or all affected bmarks would have to be invalidated.

Alternatively, instead of having both, iterators and bookmarks, I could 
imagine combining the two classes and give iterators the properties of a 
bookmark.

Currently iterators are bound closely to the underlying iterator 
algorithm, vector::iterator in this case. So they can become invalid 
after an insert operation.

Bookmarks otoh would be a much higher-level abstraction and should be 
unique for every object inside the container.

My current thinking is having bookmark as a unique 'address' of an 
element in a container. Bookmarks should remain valid for all operations.

Iterators otoh will be short-lived objects used to access and iterate 
the container. Their sort order can be changed without changing the 
actual sort order of the underlying container.

If you are familiar with databases, another way to think of bookmarks, 
containers and iterators is this:

A container is a database table. It does not have a sort order - or 
perhaps it as a default sort order.

A bookmark is just that, a bookmark. Most database engines support 
bookmarks for rows inside a table. A bookmark remains valid as long as 
the row exists, regardless of other insertion/deletion operations.

An iterator is a cursor. When you 'SELECT * FROM table' you really open 
a cursor and iterate over the table with GetFirst() and GetNext(). 
Optionally cou can pass a sort order to the SELECT statement so the 
cursor will return the objects in a particular order.


Translated to the container adapters this would mean:

// get a handle to the container (table)
container my_container=my_accessor.get_container();

// iterate over the container using a particular sort order
container::iterator i;
for (i=my_container.get_iterator("SORT BY m_name"); i.at_end()==false; ++i)

// save a bookmark for an element that iterests me
// return the bookmark for the current iterator as a long value
// associate the bookmark with the 'ItemData' property of the current 
list control element
   some_list_ctrl->SetItemData(index, i.get_bookmark().as_long());


// seek to a specific bookmark
i=my_container.get_iterator("SORT BY other_property");
i.seek(bookmark((long)some_list_ctrl->GetItemData()));




Something along these lines.

Best regards

Hajo

[litwindow-users] <map> as container

[yrs90 <yr...@ya...>]

I have been pondering <map> containers again.

The reason that <map> could not be used as a container was that it didn't
have a way to be bookmarked like a vector, is that right?  I'm not sure I
understand the limitation.  It seems that there are at least two possible
ways of dealing with bookmarks using a <map>.

If the bookmarks are refreshed when a NotifyChanged() is received, the
existing implementation of indexing off the begin() iterator looks
sufficient.  As it stands now, when a new data element is inserted or
deleted, the entire view is repopulated, so the index can be refreshed with
the updated ordering.

If the bookmark needs to persist in the face of insertions and deletions,
the iterator itself could be used as the bookmark.  <map> has the nice
feature of not invalidating the iterators when an element is inserted or
deleted (other than the deleted element).  This is less volatile than a
<vector>.

Am I overlooking something?

Best regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: change notification

[Hajo K. <mai...@ha...>]

yrs90 wrote:
> The explanation on calling NotifyChanged on physical data is much clearer
> now.  I understand the propagation paths well enough that thus far the
> results have been predictable.
> 
> I am still having trouble understanding how to take an accessor (or typed
> accessor or whatever) that I retrieve from a UI element for a call with
> NotifyChanged.  I'm still stuck referencing the physical structure directly.

Incomplete litwindow sources here.

NotifyChanged is actually a template that calls make_const_accessor for 
you and then calls RapidUI::NotifyChanged. See rapidUI.h

If you already have an accessor, calling make_const_accessor does not 
make sense.

I've added another NotifyChanged method to the headerfile that will take 
an accessor.

But you could also try using

RapidUI::NotifyChanged (static member) instead.

Hajo

[litwindow-users] change notification

[yrs90 <yr...@ya...>]

The explanation on calling NotifyChanged on physical data is much clearer
now.  I understand the propagation paths well enough that thus far the
results have been predictable.

I am still having trouble understanding how to take an accessor (or typed
accessor or whatever) that I retrieve from a UI element for a call with
NotifyChanged.  I'm still stuck referencing the physical structure directly.

Thanks,
Joel

---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: User containers?

[Hajo K. <mai...@ha...>]

yrs90 wrote:
> I'm not sure if I'm doing this right.  I'd like to mediate access to the
> container so that I know if data has changed, possibly to filter data sent
> to views, and to provide some map-like capabilities to the vector (unique
> container, named lookup).

> 
> BEGIN_ADAPTER(MyContainer)
>   PROP_I(vector<MyListItem>)
>   PROP_RW_FUNC(IsDirty, SetDirty, "Dirty")
> END_ADAPTER()
> 
> IMPLEMENT_ADAPTER_CONTAINER(vector<MyListItem>)
> 
> class ... {
>   MyContainer m_list;
> };
> 
> BEGIN_ADAPTER(...)
>   PROP(m_list)
> END_ADAPTER()

This should work, as far as I can see from studying the 
IMPLEMENT_ADAPTER_CONTAINER define. This define inserts code for a 
get_prop_type(const vector<MyListItem>*) function and if you pass a 
MyContainer object to it, the compiler should automatically cast this to 
vector<MyListItem>.

> 
> By the way, in order to do this I had to insert a space before the closing
> bracket of the PROP_I macro to avoid >>.

Fixed now, thanks. I'll check it in.

Hajo

[litwindow-users] Re: vs 2005 compilation

[Hajo K. <mai...@ha...>]

Hi,

> 
> The problem occurs after the symbol is successfully located in
> lwListAdapterBase.  It has started to unwind.  The failure occurs as at
> rc==currentAggregate.end() at line 465 of dataadapterimp.cpp.  During the
> operator== function, the iterator check occurs and, in this case, fails.

now I get it. It is actually a valid assert and has nothing to do with 
your code.

The assert fails if you are trying to compare iterators that belong to 
different containers.

Indeed the iterators here belong to different containers, but I did that 
on purpose. Hmm, seems that this is non standard. That is a bother. Why 
one shouldn't be allowed to do that is beyond me.

What I am doing here is the following: I am searching for the symbol you 
passed in. find_identifier returns an iterator to that symbol. But it 
searches for it in many different containers so the iterator returned 
might belong to a different container. Every adapter has its own base 
container, but every member and every inherited structure inside an 
adapter has a container of its own.

I will think about that and come up with a solution.

I am glad that you've found out how to continue, though.

BTW, can you please compile and run the unittests? They are meant to 
catch errors such as these.

Regards

Hajo

[litwindow-users] User containers?

[yrs90 <yr...@ya...>]

I'm not sure if I'm doing this right.  I'd like to mediate access to the
container so that I know if data has changed, possibly to filter data sent
to views, and to provide some map-like capabilities to the vector (unique
container, named lookup).

Before I had the following

class ... {
vector<MyListItem> m_list;
};

BEGIN_ADAPTER(...)
  PROP(m_list)
END_ADAPTER()

IMPLEMENT_ADAPTER_CONTAINER(vector<MyListItem>)

I tried the following:

class MyContainer : public vector<MyListItem>
{
	bool IsDirty() const;
	void SetDirty(const bool);

	// all constructors and all modification functions
	...
};

MyContainer m_list;

BEGIN_ADAPTER(MyContainer)
  PROP_I(vector<MyListItem>)
  PROP_RW_FUNC(IsDirty, SetDirty, "Dirty")
END_ADAPTER()

IMPLEMENT_ADAPTER_CONTAINER(vector<MyListItem>)

class ... {
  MyContainer m_list;
};

BEGIN_ADAPTER(...)
  PROP(m_list)
END_ADAPTER()

By the way, in order to do this I had to insert a space before the closing
bracket of the PROP_I macro to avoid >>.

Is this a valid way to proceed?

Regards,
Joel



---
[This E-mail scanned for viruses by Declude Virus]

RE: [litwindow-users] Re: vs 2005 compilation

[yrs90 <yr...@ya...>]

Alright, another update:

When last I posted, I was trying to resolve a vector iterators incompatible
assertion.

I got side tracked in my plans to fix the problem because I figured out that
I could just disable these checks by defining _HAS_ITERATOR_DEBUGGING=0 and
_SECURE_SCL=0.  Subsequently, I found
http://msdn.microsoft.com/library/en-us/dnvs05/html/VisCExSecApps.asp
discussed a little about the _SECURE_SCL flag.  

Oddly, I still had a little bit of trouble getting it to work at first.
It's never as easy as it should be.  At one point I was getting this
assertion that the iterator list was corrupted.  (After staring at it for a
while, I guessed that this was due to mismatched object sizes since I hadn't
recompiled the litwindow code.)  In the end, I recompiled the library and my
code all using the flags to disable checks.  It works again!

Now back to my other problems...


---
[This E-mail scanned for viruses by Declude Virus]

RE: [litwindow-users] Re: vs 2005 compilation

[yrs90 <yr...@ya...>]

> Did you rebuild the litwindow library with the new tools?

I did indeed.

I'm starting to understand the code a little better. The code does what it's
intended to do. I think the assertion was introduced to catch people who
compare different objects by accident.  In this case, the fact that they are
different objects is what we want to know.  If the find had failed the
original iterator would have been returned.  I think one possible solution
(assuming support for VS8 in debug mode is important) is to introduce a
first order check that asks if they iterators point to different objects.  I
am trying to decipher how to query the iterator type now.

> You don't have to. Just pass the relevant 'generate debug symbols' 
> switch to the compiler and also pass the 'create program database' 
> switch to the linker.

This is good to know. Thanks.

Regards,
Joel



---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: vs 2005 compilation

[Hajo K. <mai...@ha...>]

Hi,

yrs90 wrote:
> Oh look!  This isn't a singular problem.
> http://lists.boost.org/MailArchives/boost/msg69473.php
> 
> Still, I don't know what the implied correction is... :)  Any insight?
> 
No, none right now. I would have to look into this a bit more closely, 
but don't have the time. I guess compiling with 2005 will have to wait. 
Sorry.

Hajo

[litwindow-users] Re: vs 2005 compilation

[Hajo K. <mai...@ha...>]

yrs90 wrote:

> I'm thinking that this might not be a library problem.  I've been tracing
> through the function and I watch it iterate through the name space looking
> for "Items".  

Hm, silly question. Did you rebuild the litwindow library with the new 
tools?

> 
> This is a great idea!  The only thing is that I don't know how to extract
> the symbols from the obj files without the linkers help.

You don't have to. Just pass the relevant 'generate debug symbols' 
switch to the compiler and also pass the 'create program database' 
switch to the linker.

All you need is the program database.

Regards

Hajo

RE: [litwindow-users] Re: vs 2005 compilation

[yrs90 <yr...@ya...>]

Oh look!  This isn't a singular problem.
http://lists.boost.org/MailArchives/boost/msg69473.php

Still, I don't know what the implied correction is... :)  Any insight?

Best regards,
Joel

-----Original Message-----

> > Any idea how to resolve this assertion?  Is this a library problem too?
> Looks very much like it, I'd say.

I'm thinking that this might not be a library problem.  I've been tracing
through the function and I watch it iterate through the name space looking
for "Items".  

I conjectured that this might be related to something I mishandled in
wxCtrlListAdapter, so I've now tried it with a wxListBox and the same thing
happens.  The following uses wxListBox. (wxListCtrl followed the same path.)

The problem occurs after the symbol is successfully located in
lwListAdapterBase.  It has started to unwind.  The failure occurs as at
rc==currentAggregate.end() at line 465 of dataadapterimp.cpp.  During the
operator== function, the iterator check occurs and, in this case, fails.

The iterator rc was just returned from find_identifier via "return
nested_rc". It is at the wxListBoxAdapter level comparing to the iterator
returned on lwListAdapterBase.

rc.it._Mycont == 0x877804 while the currentAggregate.end().it._Mycont ==
0x877b04.  Since the two values of _Mycont are not equal the assertion
occurs.

The usual course is that it still turns out to be something I've done. :)
Still, any thoughts?


> I have got a question. You are using the free 2003 tools. They come 
> without the debugging libraries you say. But you could still generate 
> debugging information with the compiler, couldn't you? Then I would 
> suggest you continue to use the free tools, add the debug symbols 
> compiler switch and compile and link the whole thing. You don't need to 
> link with the debugging libraries to be able to debug. All you need is 
> debug symbols.

This is a great idea!  The only thing is that I don't know how to extract
the symbols from the obj files without the linkers help.

Regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

RE: [litwindow-users] Re: vs 2005 compilation

[yrs90 <yr...@ya...>]

> > Any idea how to resolve this assertion?  Is this a library problem too?
> Looks very much like it, I'd say.

I'm thinking that this might not be a library problem.  I've been tracing
through the function and I watch it iterate through the name space looking
for "Items".  

I conjectured that this might be related to something I mishandled in
wxCtrlListAdapter, so I've now tried it with a wxListBox and the same thing
happens.  The following uses wxListBox. (wxListCtrl followed the same path.)

The problem occurs after the symbol is successfully located in
lwListAdapterBase.  It has started to unwind.  The failure occurs as at
rc==currentAggregate.end() at line 465 of dataadapterimp.cpp.  During the
operator== function, the iterator check occurs and, in this case, fails.

The iterator rc was just returned from find_identifier via "return
nested_rc". It is at the wxListBoxAdapter level comparing to the iterator
returned on lwListAdapterBase.

rc.it._Mycont == 0x877804 while the currentAggregate.end().it._Mycont ==
0x877b04.  Since the two values of _Mycont are not equal the assertion
occurs.

The usual course is that it still turns out to be something I've done. :)
Still, any thoughts?


> I have got a question. You are using the free 2003 tools. They come 
> without the debugging libraries you say. But you could still generate 
> debugging information with the compiler, couldn't you? Then I would 
> suggest you continue to use the free tools, add the debug symbols 
> compiler switch and compile and link the whole thing. You don't need to 
> link with the debugging libraries to be able to debug. All you need is 
> debug symbols.

This is a great idea!  The only thing is that I don't know how to extract
the symbols from the obj files without the linkers help.

Regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: vs 2005 compilation

[Hajo K. <mai...@ha...>]

yrs90 wrote:
> Ok, I've rebuild wxWidgets-2.5.5, LitWindow and my project using the VS 2005
> Express Beta 2 compiler.  The compiler generates floods of warnings, most
> having to do with either macro redefinitions in conflicting header files or
> deprecated functions, but the libraries all seem to build successfully.  By
> the way, macro redefinitions occur between the SDK specstrings.h and the VS
> 8 sal.h.  The two are supposed to play together so I've assumed that its not
> a problem.
> 
> I spent about 8 painstaking and painful hours resolving linking issues. The
> most troublesome problems were related to having some mixed library versions
> that I couldn't locate.

Oh dear. I'd break it off then.

> Any idea how to resolve this assertion?  Is this a library problem too?

Looks very much like it, I'd say.

I have got a question. You are using the free 2003 tools. They come 
without the debugging libraries you say. But you could still generate 
debugging information with the compiler, couldn't you? Then I would 
suggest you continue to use the free tools, add the debug symbols 
compiler switch and compile and link the whole thing. You don't need to 
link with the debugging libraries to be able to debug. All you need is 
debug symbols.

Then you can use the VC 2005 IDE debugger to debug the code you've 
generated with the free tools.

Hajo

RE: [litwindow-users] vs 2005 compilation

[yrs90 <yr...@ya...>]

> Now it compiles and links, but upon execution I get a debug assertion
> stating "vector iterators incompatible".  
> Any idea how to resolve this assertion?  Is this a library problem too?

Okay I can localize the assertion to the rule that assigns the vector to the
listctrl when handled by Start().  With the rule commented out or with
Start() commented out (not so surprising really), I can start the program
without any assertions.

My rule is of the form
	RULE("xrcListCtrl", make_expr<accessor>("m_myVector"))

where m_myVector, although embedded in a class, is of the form

class MyListItems;
vector<MyListItems> m_myVector;
IMPLEMENT_ADAPTER_CONTAINER(vector<MyListItems>)

The assertion occurs in RapidUI::Start at line reading
	(*i)(*this);

The iterator used is defined
	RulesList::const_iterator i;

Time for a break.

Regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] vs 2005 compilation

[yrs90 <yr...@ya...>]

Ok, I've rebuild wxWidgets-2.5.5, LitWindow and my project using the VS 2005
Express Beta 2 compiler.  The compiler generates floods of warnings, most
having to do with either macro redefinitions in conflicting header files or
deprecated functions, but the libraries all seem to build successfully.  By
the way, macro redefinitions occur between the SDK specstrings.h and the VS
8 sal.h.  The two are supposed to play together so I've assumed that its not
a problem.

I spent about 8 painstaking and painful hours resolving linking issues. The
most troublesome problems were related to having some mixed library versions
that I couldn't locate.

Now it compiles and links, but upon execution I get a debug assertion
stating "vector iterators incompatible".  The assertion is from the
following portion of #include <vector>

#if _HAS_ITERATOR_DEBUGGING
       void _Compat(const _Myt& _Right) const
               {       // test for compatible iterator pair
               if (this->_Mycont == 0 || this->_Mycont != _Right._Mycont)
                       {
                       _DEBUG_ERROR("vector iterators incompatible");
                       _SCL_SECURE_INVALID_ARGUMENT;
                       }
               }
#endif /* _HAS_ITERATOR_DEBUGGING */

If I ignore the first assertion, I get an assertion expression of ("SCL
Secure Invalid Argument", 0).

Any idea how to resolve this assertion?  Is this a library problem too?


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] VS Express 2005 Beta (was Re: operator= no type specified)

[Hajo K. <mai...@ha...>]

yrs90 wrote:
> I loaded VS Express 2005 Beta 2.  It looks like it includes the debug stl
> libraries.  Interestingly, I got the following errors while compiling the
> LitWindow library.

Yes, several options are no longer supported.

> lwbase\include\litwindow\dataadapterimp.h(1089) : error C4430: missing type
> specifier - int assumed. Note: C++ does not support default-int

> The two errors above are WRT to the type declaration for operator=.  Indeed,
> this needs a type.  I wonder why it didn't complain about this with the
> prior compiler.  They are declared private so perhaps you're not using them
> yet.

Thanks. I'll update that in the source. Declaring copy constructor and 
operator= as private prevents the class from being copied. 
constraint_solver objects currently cannot be copied because of pointers 
inside them.

Hajo

[litwindow-users] operator= no type specified

[yrs90 <yr...@ya...>]

I loaded VS Express 2005 Beta 2.  It looks like it includes the debug stl
libraries.  Interestingly, I got the following errors while compiling the
LitWindow library.

cl : Command line warning D9035 : option 'GX' has been deprecated and will
be removed in a future release cl : Command line warning D9036 : use 'EHsc'
instead of 'GX'
cl : Command line warning D9035 : option 'GZ' has been deprecated and will
be removed in a future release cl : Command line warning D9036 : use 'RTC1'
instead of 'GZ'
cl : Command line warning D9002 : ignoring unknown option '/YXstdafx.h'

constraints.cpp
lwbase\include\litwindow\dataadapterimp.h(1089) : error C4430: missing type
specifier - int assumed. Note: C++ does not support default-int
lwbase\include\litwindow/constraints.h(507) : error C4430: missing type
specifier - int assumed. Note: C++ does not support default-int

The two errors above are WRT to the type declaration for operator=.  Indeed,
this needs a type.  I wonder why it didn't complain about this with the
prior compiler.  They are declared private so perhaps you're not using them
yet.

Presumably dataadapterimp.h(1089) should read schema_base& operator=(const
schema_base&);

and constraints.h(507) should read
constraint_solver& operator=(const constraint_solver&);

Well, not exactly a diff... :)

Best regards,
Joel


---
[This E-mail scanned for viruses by Declude Virus]

[litwindow-users] Re: Using aggregate/accessors

[Hajo K. <mai...@ha...>]

Hi,

>>What do you pass to "Items"?
> 
> 
> I am passing a vector<class MyListData> to Items.
> 
> Specifically, 
> 
> RULE("xrcMainList.Items", make_expr<accessor>("m_ListData"))

ah, of course. Tiny detail, big effect. I didn't pay close enough 
attention. You are not passing a vector<>, you are passing an accessor 
to a vector. Thats the same difference between Type and Type*. The 
accessor is like Type*. You need to dereference the accessor to get to 
the vector.

On the wxListCtrl side:

Items is not a vector<MyListData>, its an accessor, which in your 
situation currently happens to point at a vector<MyListData> but could 
point to a totally different data type a few microseconds later.

So you have

wxListCtrl *pList = wxDynamicCast(event.GetEventObject(), wxListCtrl);
aggregate ag(make_aggregate(*pList));
accessor ac(ag["Items"]);

ag["Items"] returns an accessor to the property. If the property is of 
type long, it returns an accessor to a long object. If the property is 
of type string, it returns an accessor to a string object.
In your case, the property is an accessor, so ag["Items"] returns an 
accessor to an accessor object.

To get to the real accessor, the one you are interested in, you must 
dereference the accessor, much like *ag["Items"].

But accessors are untyped objects, so you need to cast it into a typed 
accessor first, then dereference it. Here is how:

     typed_accessor tac=dynamic_cast_accessor<accessor>(ac);
     accessor the_real_items_accessor=tac.get(); // this is like '*ac'
     the_real_items_accessor.is_container()==true;




I'll rewrite the scenario using pseudo-code and replace accessor with 
'void*' to make things more clear.

wxListCtrl *pList=wxDynamicCast...
aggregate ag(make_aggregate(*pList));

// ag["Items"] returns a void* to the "Items" member property
// which is itself of type void*
// so ag["Items"] return type is void **
void **ac=ag["Items"]; // ag.Items

// cast it so we can get to the data

void *tac=*(void*)ac;
vector<MyDataStruct> *the_real_items_accessor=(vector<...>*)tac;



    ***
Here is the full version again, that should work now:

wxListCtrl *pList = wxDynamicCast(event.GetEventObject(), wxListCtrl);
aggregate ag(make_aggregate(*pList));
accessor ac(ag["Items"]);

typed_accessor tac=dynamic_cast_accessor<accessor>(ac);
accessor the_real_items=tac.get();

if (the_real_items.is_valid() && the_real_items.is_container())


Looks more complicated than it is until you think of accessors as void* 
pointers with type information, which is exactly what they are by the way :)


Hajo