*** reinhard has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> good morning
<reinhard> good morning all
*** derek has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** derek has quit IRC
*** exo_ has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
<johannesV> osx-packages of prereleases are updated ...
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** exo_ has quit IRC
*** derek has quit IRC
*** siesel has joined #gnuenterprise
*** btami has joined #gnuenterprise
<btami> hi all
<btami> reinhard: seems appserver needs beta2 too
<btami> just tested forms/common beta2 with appserver beta1, and the sample form doesn't work
<btami> you made this fix after beta1
<btami> http://www.gnuenterprise.org/cgi-bin/viewcvs.cgi/trunk/gnue-appserver/src/language/Object.py?rev=8194&view=log
<reinhard> btami: thanks for the hint. beta2 already building
<btami> ok, thx
* reinhard hugs his gnue-common/tools/release script :)
<btami> btw. appservers version is shorter than forms/common, is it on purpose ?
<reinhard> yes
<btami> ok
<reinhard> appserver is heading to 0.6.0
<reinhard> so it's 0.5.99
<btami> cool :)
<reinhard> forms is heading 0.5.14
<reinhard> so it's 0.5.13.99
<reinhard> this reminds me that I'd actually like to see a better release planning
<reinhard> and structure
<reinhard> I mean
<reinhard> forms 0.5.14 is *way* off from what 0.5.0 was
<reinhard> and I think third number should only be fixes
<reinhard> so I'd envision something like
<reinhard> 0.6-alpha1
<reinhard> 0.6-alpha2
<reinhard> 0.6-alpha3
<reinhard> 0.6-beta1
<reinhard> 0.6-beta2
<reinhard> 0.6-pre1
<reinhard> 0.6-pre2
<reinhard> 0.6.0
<reinhard> 0.6.1
<reinhard> 0.6.2
*** siesel has quit IRC
*** jamest has joined #gnuenterprise
<jamest> morning
<jamest> (for me)
<btami> reinhard: agreed
<btami> jamest: good morning
<jamest> reinhard: i was going to work on the sample tonight you mentioned wanting a fishhook and all datatypes
<jamest> any other things you want to see in there
<reinhard> naturally master/detail
<reinhard> master/detail/detail would be good, as there have been bugs only appearing in 3-level case
<jamest> wddl
<reinhard> (would be customer/invoice/invoice-item)
<jamest> well
<jamest> ok, can do
<jamest> i've already got in there
<jamest> invoice - invoice_address - address
<jamest> address == street address, invoice address = attention lines + valid from date + invoice_id and address_id
<jamest> and I know I need to add a boolean
<jamest> did you want date as well as datetime?
<reinhard> yes
<jamest> and I figured items table could hook back to itself
<jamest> with a replacement_id
<reinhard> yes
<reinhard> we also have time values
<reinhard> (time without date)
<reinhard> they are especially interesting
<reinhard> must run, bbl
<jamest> ok, i've not ever had use for something like that so I'm not sure where'd i'd graft that in, ideas?
*** jcater has joined #gnuenterprise
*** btami has quit IRC
*** btami has joined #gnuenterprise
*** klasstek has joined #gnuenterprise
<johannesV> hmm
<johannesV> reinhard, could you have a look at this (when you're back):
<johannesV> Traceback (most recent call last):
<johannesV>    File "<unknown_executioncontext>", line 30, in __main_____GF_1241603860_pgContact___GF_1241602100_ON_ACTION
<johannesV>    File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/common/logic/NamespaceCore.py", line 324, in __call__
<johannesV>     return self._objectFunction(*args, **kwargs)
<johannesV>    File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/common/datasources/GDataSource.py", line 171, in __trigger_createResultSet
<johannesV>     return self.createResultSet (conditions, readOnly)
<johannesV>    File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/common/datasources/GDataSource.py", line 574, in createResultSet
<johannesV>     resultSet = self.__createResultSet (conditions, readOnly, masterRecord)
<johannesV>    File "/home/johannes/prj/gnue/.cvsdevelbase/gnue/common/datasources/GDataSource.py", line 634, in __createResultSet
<johannesV>     mastercond [detailfield] = masterRecord.getField (masterfield)
<johannesV>  AttributeError: 'NoneType' object has no attribute 'getField'
<johannesV> this happens if i do a dts.createResultSet (cond, query = True) where "dts" is a detail-datasource
*** johannesV_ has joined #gnuenterprise
*** johannesV_ has quit IRC
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** derek has joined #gnuenterprise
<reinhard> johannesV_: you may not do this kind of query
<reinhard> there is some special way to do query by detail
*** sjc has joined #gnuenterprise
*** sacha_ has joined #gnuenterprise
<reinhard> err of course
<reinhard> you have to do a GCexists query
<reinhard> so you actually can build one single query
<reinhard> where name1 = param OR name2 = param OR GCexists (contact.name = param)
<reinhard> of course with s/=/like/
<johannesV_> ah, but doing that query on the master source
*** sacha has quit IRC
<btami> win packages of prereleases uploaded...
<reinhard> thanks
*** derek has quit IRC
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** klasstek has quit IRC
*** klasstek has joined #gnuenterprise
*** btami has quit IRC
*** sacha_ has quit IRC
*** jamest has quit IRC
*** jamest has joined #gnuenterprise
*** johannesV_ has quit IRC
<jamest> reinhard: how did parameter support in forms change recently?
<jamest> as svn head broke all my parameter forms
<reinhard> uhmmm
<reinhard> it should not
<jamest> the trigger namespace function references
<jamest> GFForm._parameters
<jamest> which no longer exists
<jamest> getParameter
<jamest> i'm tracing thru it now but I forgot to test a parameter form prior to deploying today
<jamest> or as jcater would say "prior to passing it on to the QA department"
<reinhard> hmmm
<reinhard> GFInstance.py line 356
<reinhard>     form._parameters = parameters
<reinhard> so every GFForm should have a _parameters
<reinhard> (this line is in activateForm)
<jamest> ok
<jamest> it would
<jamest> but the secondardInit in GFForm fires the on-startup trigger
<reinhard> ah
<reinhard> and you use parameters in on-startup?
<reinhard> that's probably the only place where they don't work ;-)
<jamest> probably
<jamest> i'm thinking about moving that to on-activation
<jamest> as it should still work for a main form
* jamest recalls the on-activation gave dialog forms a chance to set themselves up
<jamest> but i still wonder if the on-startup parameter issue should be concidered a bug
<jamest> as it shouldn't choke
<reinhard> sure it should be considered a bug
<reinhard> but I have no idea how to fix it best
<reinhard> *sigh* we haven't found a way to deal with parameters that works for every case...
<reinhard> I don't know if there is any chance to pass the parameters to the form before it is activated
<jamest> how are parameters handled now?
<reinhard> they are passed to activateForm
<reinhard> so they are available from activation
<reinhard> for the __main__ form, the command line parameters are passed
<reinhard> and for dialogs, the parameters are passed that were given in runDialog (or how that was called)
<reinhard> most notably they should be available in ON-ACTIVATE
<reinhard> damn, I got my new notebook today, and now breezy doesn't run on it :((
<reinhard> sata problem with 2.6 kernel
<reinhard> sarge installs fine however
<jamest> is sarge the current release?
* jamest is blanking
<jamest> ah yeah
<jamest> reinhard: you might give ubuntu a try
<reinhard> breezy is ubuntu :)
<jamest> lol
<reinhard> I guess I'll run with sarge for now and try again when next ubuntu is out
<jamest> i switched to it on my home system last weekend
<jamest> as I always fought my dual head setup
<jamest> and kubuntu was far easier to get it running for some reason
<reinhard> well it's a known problem with the ide/sata chip and the 2.6 kernel - there are 2 modules that think they should handle that chip, and the wrong one wins
<jcater> lol
<jcater> I had the opposite problem with sarge/sata on one of my servers
<jcater> I still installed sarge though :)
<reinhard> good night all
*** reinhard has quit IRC
*** jamest has quit IRC
*** kilo has joined #gnuenterprise
*** klasstek has quit IRC
*** kilo has left #gnuenterprise
*** derek has quit IRC
*** jamest has joined #gnuenterprise
*** sjc has quit IRC
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** sacha has joined #gnuenterprise
*** jcater has left #gnuenterprise
*** derek has joined #gnuenterprise
*** jamest has left #gnuenterprise