litwindow-users — how to use the litwindow library

Re: [litwindow-users] Re: unresolved external symbol

[Jake S. <ja...@za...>]

> Creating library Debug/RossClient.lib and object Debug/RossClient.exp


I just noticed that it is trying to create a library! I don't get it, I
will double check things.

jake

[Fwd: Re: [litwindow-users] Re: unresolved external symbol]

[Jake S. <ja...@za...>]

Hajo Kirchhoff wrote:

> I cannot remember if I the library already includes the wxString data
> adapter. Could you please try this:


I think it does, rssreader is fine with wxString and wxDateTime.

> remove all members from Company except m_compName
> change wxString m_compName to string m_compName...
> change string m_compName to int m_compName...
> try again and post the results here.


In MainFrame.h
struct Company
{
  int m_compName;
};

In MainFrame.cpp
#include <litwindow/dataadapter.h>
using namespace litwindow;
BEGIN_ADAPTER(Company)
    PROP(m_compName)
END_ADAPTER()

I got exactly the same result, everything compiled and then had trouble
linking.

Linking...
   Creating library Debug/RossClient.lib and object Debug/RossClient.exp
MainFrame.obj : error LNK2001: unresolved external symbol "void __cdecl
litwindow::not_implemented(class _STL::basic_string<char,class
_STL::char_traits<char>,class _STL::allocator<char> > const &)"
(?not_implemented@litwindow@@YAXABV?$basic_string@
DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@Z)
Debug/RossClient.exe : fatal error LNK1120: 1 unresolved externals

When I used string for m_compName;

Linking...
   Creating library Debug/RossClient.lib and object Debug/RossClient.exp
MainFrame.obj : error LNK2001: unresolved external symbol "void __cdecl
litwindow::not_implemented(class _STL::basic_string<char,class
_STL::char_traits<char>,class _STL::allocator<char> > const &)"
(?not_implemented@litwindow@@YAXABV?$basic_string@
DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@Z)
MainFrame.obj : error LNK2001: unresolved external symbol "public:
static class litwindow::converter_base * __cdecl
litwindow::prop_type_object<class _STL::basic_string<char,class
_STL::char_traits<char>,class _STL::allocator<char> > >::get(class _S
TL::basic_string<char,class _STL::char_traits<char>,class
_STL::allocator<char> > const *)"
(?get@?$prop_type_object@V?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@@litwindow@@SAPAVconverter_base@2@PBV?$basic_string@DV?$char_traits@
D@_STL@@V?$allocator@D@2@@_STL@@@Z)
Debug/RossClient.exe : fatal error LNK1120: 2 unresolved externals

I had an extra unresolved external.

>
> Are you building debug or release version? Are you using the visual
> studio compiler?

I am using the debug lib version of litwindow on XP SP2, VC++6, wx2.5.3,
and STLport (sorry for not including that basic info)

>
> Regards
>
> Hajo
>
> P.S. I am currently meeting with Julian Smart in Edinburgh so you can
> expect more and better wxWidgets integration in the future. Being in
> Edinburgh also means that I might be more slow to answer.

I saw that on the litWindow website - can only be a good thing :)

I'm sure that this problem is to do with me, but I'm stumped as to what
it is - I am linking to both lwbase_md.lib and lwwx_md.lib.

Regards
Jake

[litwindow-users] Re: unresolved external symbol

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

Jake Skinner wrote:
> struct Company
> {
> 	wxString	m_compName;
> };
> 
> And now the macros
> BEGIN_ADAPTER(Company)
> 	PROP(m_compName)
> END_ADAPTER()
> 
> IMPLEMENT_ADAPTER_CONTAINER(vector<Company>)
> 
> cheers
> jake
> 

Hi Jake,

not_implemented is a function that is called by incomplete data 
adapters, i.e. when a from_string method is missing. It shouldn't turn 
up as a missing symbol though.

I cannot remember if I the library already includes the wxString data 
adapter. Could you please try this:

remove all members from Company except m_compName
change wxString m_compName to string m_compName...
change string m_compName to int m_compName...
try again and post the results here.

Are you building debug or release version? Are you using the visual 
studio compiler?

Regards

Hajo

P.S. I am currently meeting with Julian Smart in Edinburgh so you can 
expect more and better wxWidgets integration in the future. Being in 
Edinburgh also means that I might be more slow to answer.

Re: [litwindow-users] unresolved external symbol

[Jake S. <ja...@za...>]

I said:

>I'm just trying to incorporate litWindow and when compiling my source
>code, I am getting the following message.
>
>unresolved external symbol "void __cdecl
>litwindow::not_implemented(class _STL::basic_string<char,class
>_STL::char_traits<char>,class _STL::allocator<char> > const &)"
>
>I'm a little lost where to start looking. I assume that I have done
>something wrong.
>
>rssreader compiles and runs fine.


This unresolved symbol, becomes apparent when I add the data adapter macros

Below is the data struct - very basic
struct Company
{
	wxString	m_compName;
	wxString	m_contact;
	wxString	m_street;
	wxString	m_suburb;
	wxString	m_postCode;
	wxString	m_state;
	wxString	m_country;
	wxString	m_phone;
	wxString	m_fax;
	wxString	m_email;
	wxString	m_website;
	wxString	m_notes;
};

And now the macros
BEGIN_ADAPTER(Company)
	PROP(m_compName)
	PROP(m_contact)
	PROP(m_street)
	PROP(m_suburb)
	PROP(m_postCode)
	PROP(m_state)
	PROP(m_country)
	PROP(m_phone)
	PROP(m_fax)
	PROP(m_email)
	PROP(m_website)
	PROP(m_notes)
END_ADAPTER()

IMPLEMENT_ADAPTER_CONTAINER(vector<Company>)

cheers
jake

[litwindow-users] Re: litwindow error

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

Eugen Popovici wrote:
> void rule_base::execute_immediate(const constraint_solver *a_solver) const
> 
> {
> 
> auto_ptr<value_assign_base> v(evaluate(a_solver));
> 
> _if( NULL != v.get() )_ v->do_assign(a_solver->get_symbol_table());
> 
> }

Thank, will fix in CVS head soon.

Please excuse the delay, I am bit overworked at the moment.

Hajo

[litwindow-users] Implementing generic UI patterns (was Re: add/modify/delete pattern)

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

Hi Jake,

(this is a cross post from gmane.comp.lib.litwindow.user that hopefully 
is also of interest to the current GUI discussion on the boost list. The 
question was how to write a generic implementation for the 
add/modify/delete user interface pattern)

Jake Skinner wrote:
> I am having some difficulty getting my head around the RULE syntax and
> what can be achieved. I am trying to implement the add/modify/delete
> pattern which appears to have been catered for.
> 

you are a bit ahead of the litwindow schedule here.

I've put up a new article on the website (a correction of the few layout 
problems will appear later this day)

http://www.litwindow.com/Library/Articles/rapidui_article_3.htm

Here is what works:

You can already handle the 'modify' part of the add/modify/delete 
pattern. Have a look at the RSS Reader tutorial, Step 3 and 4 in the 
documentation.

Here is what does not yet work:

Action rules have yet to be defined. So you cannot fire an action using 
the rules and that is the reason why the add/modify/delete rule has to 
be written yet.

To implement Add you will have to intercept the event yourself.

What you can do is write a generic algorithm to add a new element and 
show it. Here is the rough outline:

void AddElement(RapidUI &r, string listBoxName)
{
     // first get the aggregate object for the list box
   aggregate listbox=r.GetWindowAccessor(listBoxName).get_aggregate();
     // next get a container object for the "Items" property
     // of the list box
   container items=listbox["Items"];
   if (items.is_valid()==false) {
     lw_log() << "Cannot add! List box is not attached to a container.";
     return;
   }
     // now get an accessor to the currently selected element
   accessor element=listbox["Current"];
     // this accessor will contain valid *type* information
     // even if no *current* element is selected

     // the next line will create a new object on the heap with 'new'
     // the new object will have the same type as 'Current'
   accessor newObject=create_object(element.get_type());

     // insert it (copying it) at the first position into the container
   items.insert(items.begin(), newObject);
     // delete the temporary object since a copy of it is now contained
     // in the container
   newObject.destroy();

     // finally tell RapidUI to update the UI
     // this will update the list box and the new element will
     // be shown at position 1
   r.ValueChanged(items.get_accessor(), false, false);
}

This is a generic function, meaning that it will work
- with any kind of container
- with any type of elements contained in the container
- with any list widget that knows "Items" and "Current"

provided the appropriate data adapters have been created.

Hope this helps and thank you for your interest.

BTW, I am cc-ing this to the boost mailing list

Regards

Hajo

Speed up GUI coding by a factor of 10x
http://www.litwindow.com/library

[litwindow-users] add/modify/delete pattern

[Jake S. <ja...@za...>]

Hello all,

I am having some difficulty getting my head around the RULE syntax and
what can be achieved. I am trying to implement the add/modify/delete
pattern which appears to have been catered for.

Is there anywhere that I can find more on this? I have looked around the
litwindow website, but I was hoping this might shortcut that process.

Hajo, this is a great idea and even better for actually being
implemented! :)

thanks
jake

[litwindow-users] litwindow error

[Eugen P. <eu...@qn...>]

Runtime-Error in LitWindow for method:
void rule_base::execute_immediate(const constraint_solver *a_solver) =
const {

auto_ptr<value_assign_base> v(evaluate(a_solver));

v->do_assign(a_solver->get_symbol_table());

}

Method rule_base::execute_immediate(const constraint_solver *a_solver) =
can lead to memory access violation.
Reason: local variable auto_ptr<value_assign_base> v can evaluate to =
NULL if the target is itself an accesor.

Correction:

void rule_base::execute_immediate(const constraint_solver *a_solver) =
const

{

auto_ptr<value_assign_base> v(evaluate(a_solver));

if( NULL !=3D v.get() ) v->do_assign(a_solver->get_symbol_table());

}



--

Eugen Popovici

Re: [litwindow-users] Re: hello

[Peter D. <pd...@gm...>]

On Thu, 11 Nov 2004 09:22:38 +0100, Hajo Kirchhoff <mai...@ha...> wrote:

> Peter Damoc wrote:
>> Wouldn't a more dynamic language like python be more suited for rapid UI
>> development?
>
> The goal of the library is to cater to as many developers as possible.
> That is one of the reasons for choosing C++, but see below.
>
>> Are python bindings to litwindow planned?
>
> Definitely yes. Would you be interested in contributing? A small 'proof
> of concept' would be great.

This is way out of my league  I'm just an amateur using python as a prosthesis for my exacerbated laziness.
Anyway... the way I see it... python is better suited for the job litwindow is aiming.
Any serious C++ programmer could learn python in about... let's say one day... and wxpython maybe in about aaa... one
weekend. Ok... it might get more thant that to become proficient but still it beats C++.

The path is easier in my view comming from python... something like in:
- implement some concept mega-smart widget in python using wxpython, clear out the bugs and then port it into C++ for
eficienty (if necessary).

> Best regards
>
> Hajo Kirchhoff

-- 
Peter Damoc
Hacker Wannabe
http://www.sigmacore.net/

[litwindow-users] RE: litwindow compile error

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

Hi Eugen,

thanks for your feedback. Would you consider subscribing to the
litwindow-users mailing list
http://lists.sourceforge.net/lists/listinfo/litwindow-users to share your
experience with others? Thanks a lot.

  I use as compiler Intel Compiler v6.0 integrated in Microsoft Visual
Studio v6.0.

Hey, interesting. This is the first attempt I know of to use a different
compiler.
  LWBASE_EXTERN template class LWBASE_API std::allocator<type>; \
  This macro will compile fine if use:

  LWBASE_EXTERN class LWBASE_API std::allocator<type>; \

So omitting the 'template' keyword makes it work for you. Will it still
compile with the original MS v6.0 compiler then?

  This macro will compile fine if use:

  #define PROP_I(base) \

  ::litwindow::schema_entry((litwindow::schema_entry::cast_derived_to_base_t
)&litwindow::cast_this_to_base_class<PROPCLASS, base >::cast_this_to_base,
litwindow::get_prop_type<base>(), #base),

Right.

Could you post the error messages of your compiler as well?

Best regards

Hajo

[litwindow-users] Re: hello

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

Peter Damoc wrote:
> Wouldn't a more dynamic language like python be more suited for rapid UI 
> development?

The goal of the library is to cater to as many developers as possible. 
That is one of the reasons for choosing C++, but see below.

> Are python bindings to litwindow planned?

Definitely yes. Would you be interested in contributing? A small 'proof 
of concept' would be great.

Best regards

Hajo Kirchhoff

[litwindow-users] Lit Window Mailing Lists now available as news (nntp:) feed via gmane...

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

Hello all,

all four litwindow mailing lists are now also accessible via the
news-gateway gmane (www.gmane.org). All email addresses will automatically
be encrypted, so email harvesting programs shouldn't have a change. But it
is still a good idea to use a junk email account.

If you prefer a newsreader above your email client for discussions, you can
get the litwindow news feed at

http://dir.gmane.org/gmane.comp.lib.litwindow.user

and the other lists at

http://dir.gmane.org/index.php?prefix=gmane.comp.lib

I will post the exact nntp: addresses once these lists have been created.


The litwindow development is still in its early stages so the traffic is
still very low.

Regards

Hajo Kirchhoff

--------------------------------------------
Lit Window Library - Speed up GUI coding 10x
  http://www.litwindow.com/library?src=ml

wxVisualSetup - integrate wxWidgets into Visual Studio .NET
  http://www.litwindow.com/Products/products.html?src=ml

BugLister - Defect Tracker
  http://www.litwindow.com/buglister?src=ml

Tips & Tricks for wxWidgets & MS Visual Studio
  http://www.litwindow.com/Knowhow/knowhow.html?src=ml
----------------------------------------------------------

[litwindow-users] hello

[Peter D. <pd...@gm...>]

I've skimmed through the docs on the site and I have some questions:

Wouldn't a more dynamic language like python be more suited for rapid UI development?
Are python bindings to litwindow planned?

-- 
Peter Damoc
Hacker Wannabe
http://www.sigmacore.net/