<br><br><div class="gmail_quote">On Tue, Apr 23, 2013 at 5:04 PM, Akash Shetye <span dir="ltr"><<a href="mailto:shetyeakash@gmail.com" target="_blank">shetyeakash@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div><div></div>Hey again,<br><br></div>Thanks for the reply, it really helps to know and discuss the task before putting in a proposal. Sorry for the quick and dirty solution, well thats what came to my mind right away. :P. So here is what I gather so far:<br>


<br></div><b>Alternating colors in database ranges "</b><b>very similar to the Format as Table":<br></b><ul><li>Unlike MSExcel, LO has no support for Table entities. When 'Format as Table' is done on a bunch of data in excel, the selected data is now available as a 'Table' entity, having it's own specialized attributes like row headers, total row etc and it's syntax (<a href="http://office.microsoft.com/en-in/excel-help/using-structured-references-with-excel-tables-HA010155686.aspx" target="_blank">check this</a>). <br>
</li></ul></div></div></blockquote><div> Actually LibreOffice does already have an equivalent concept called 'Range'. See from the menu Data -> Define Range. This task would involve expanding that existing Range feature to support formatted table like option etc.</div>
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul>
</ul><div class="im"><p><b>New reference syntax in formula expressions:<br></b> </p></div><ul><li>Currently I can enable the column label by selecting Data->Define Database Range ---> click "More" and tick the column headers checkbox.</li>

<li>We can address the entire range only currently thus =SUM(col_label) is valid and supported in LO, however addressing an individual cell or a range of cells within the range using col_label is not supported, implementing this is what the second part is about.</li>
</ul></div></div></blockquote><div>Well, you can disregard that =SUM(col_label) thing since that has no relation to the database range. In fact, I'm not sure if that's supposed to work like that...  It appears to pick up *any* string cell value even outside database ranges. This is very weird....<br>
<br>Anyway, what needs to be implemented is to, given a table name and a column label inside the table, allow formula to reference a range like =SUM(TableName[ColLabel]), =TableName[[#Headers],[ColLabel]] and so on.<br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul>
<li>Later we could try to figure an appropriate syntax, it would be better to consult the devs and UX guys for that.<br></li></ul></div></div></blockquote><div>We'll just use Excel's syntax. There is no need to reinvent the wheel here. Doing anything different would unnecessarily introduce an interoperability issue and there is no reason why we should use a different syntax (rather than just being different). No UX involvement is needed since this is just a basic formula syntax.<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><ul><li></li></ul><p><b>Demonstrating some competency in the areas relevant to the project:</b></p>
<ul><li>I tried searching for bugs involving the mentioned areas, they seem hard to come by. Most of those involving ScDBData are more about .xls and open document incompatibilities. <br>
</li><li>Perhaps you could point me to a bug or throw some keywords at me which would lead me to it.</li><li>Meanwhile, I have found<a href="https://bugs.freedesktop.org/show_bug.cgi?id=53920" target="_blank"> this bug</a>, it seems to be a little off our relevant area though.</li>
</ul></div></div></blockquote><div>It doesn't have to be an easy hack. Technically you've already done an easy hack, so you can just start reading the code around ScDBData, and make some "interesting" change. I really don't care what the change is, as long as you think the change should demonstrate your familiarity with the code, and your competency with working with that area of the code.<br>
</div></div><br>Hope this helps.<br><br>Kohei<br>