ANN: XLSGrid For wxPython

[Andrea Gavana]

Hi All,
    

    it's been a while since my last "announcement"... Anyway, I am happy to announce the birth of my latest child, XLSGrid.


Source code:

http://xoomer.virgilio.it/infinity77/Zipped/XLSGrid.zip

Screenshots:

(XLSGrid standalone)

http://xoomer.virgilio.it/infinity77/Softwares/XLSGrid_1.png

(XLSGrid against Excel, same file)

http://xoomer.virgilio.it/infinity77/Softwares/XLSGrid_3.png

@Robin and other wxGrid gurus (which group I am not part of, unfortunately), a couple of questions at the end of the message. Any suggestion is more than welcome.

@Warning: XLSGrid **requires** the xlrd package from:

http://pypi.python.org/pypi/xlrd

@Warning: XLSGrid has been tested on Windows Vista/Windows 7 with wxPython 2.8.11 unicode and Python 2.5, and wxPython 2.9.2.1 unicode and Python 2.7.

So, what is XLSGrid?

XLSGrid is a class based on `wx.grid.Grid` that can be used to faithfully
reproduce the appearance of a Microsoft Excel spreadsheet (one worksheet
per every instance of XLSGrid).

XLSGrid is a completely owner-drawn control, and it relies on the power of
wx.grid.PyGridTableBase and wx.grid.PyGridCellRenderer to draw the cell
content. For this reasons (and for some others, see the TODOs section), 
it will work efficiently only for relatively small Excel files.

*NOTE*: On Windows, it is **strongly** recommended to install Mark 

Hammonds' `pywin32` package:

http://sourceforge.net/projects/pywin32/

This will allow you to perfectly reproduce the appearance of the Excel

worksheet in your instance of XLSGrid.

*WARNING*: If Mark Hammonds' `pywin32` package is not available, the

formatting capabilities of XLSGrid are severely limited; for instance, 

you won't probably get the exact WYSIWYG between the Excel spreadsheet

and XLSGrid.

*WARNING*: XLSGrid can only read Excel `.xls` files, not the newer versions
`.xlsx` generated by Office 2007/2010. If you have a `.xlsx` file, you will
need to save it in 1997-2003 Office compatibility mode.

Currently this class provides a read-only subclass of `wx.grid.Grid`, with
the following formatting features already implemented:

* Cell background: support for any cell background colour and fill pattern
  (hatching) in the Excel default set. There currently is no support for
  gradient shading inside a cell as `xlrd` doesn't report this information.

* Cell borders: support for all the border types and colours exposed by 

  Excel (left, top, bottom, right and diagonal borders, thin, double, 

  thick, ect... line styles).

* Cell text: support for all kind of fonts (except strike-through, but this

  is a bug in wxWidgets), and font colours. As a subset of text/font
  capabilities, XLSGrid supports the following features found in Excel:

  - Horizontal alignment: left, right, centered, left-indented;
  - Vertical alignment: left, right, centered;
  - Text direction: left-to-right or right-to-left;
  - Text-wrapping: wrapping long texts inside a grid cell;
  - Shrink-to-fit: text font is reduced until the text can fit in a one-line
    inside the grid cell;
  - Text rotation: text can be rotated from +90 to -90 degrees.

* Cell text appearance: if you are using Mark Hammonds' `pywin32` package,

  the text displayed in the XLSGrid cells has exactly the same appearance

  as in the Excel spreadsheet.

* Cell comments (notes): if you are using Mark Hammonds' `pywin32` package,
  cell comments (notes) are extracted and you will see a small red triangle

  at the top-right corner of any cell containing a comment. Hovering with

  the mouse on that cell will pop-up a "comment-window" displaying the 

  comment text (the comment window is based on wx.lib.agw.supertooltip).

* Cell hyperlinks: starting from version 0.7.2 (SVN), `xlrd` is capable of
  extracting hyperlinks from Excel cells. This will be appropriately displayed
  in XLSGrid with a cursor changing and a tooltip on that cell.

* Cell merging: merged cells in the Excel spreadsheet will be correctly 

  handled by XLSGrid.

* Columns and rows sizes: XLSGrid calculates the correct rows and columns
  sizes based on the Excel reported values in characters. The calculations

  are based on the default width of the text in 1/256 of the width of the

  zero character, using default Excel font (first FONT record in the Excel

  file).

Questions:

1) I have this piece of code in the XLSGrid implementation (which is currently commented out):

        # Commented-out section

        # if self.attr is not None:

        #     self.attr.IncRef()

        #     return self.attr

        

        attr = gridlib.GridCellAttr()

        attr.SetRenderer(XLSRenderer(self))

        attr.SetSize(*self.size)

        attr.SetOverflow(True)

        self.attr = attr

        

        return self.attr

I though I could store a wx.grid.GridCellAttr inside a class member, but every time I try to un-comment that section I get this from wxPython 2.8.11:

Traceback (most recent call last):

  File "E:\MyProjects\temp\XLSGrid.py", line 1553, in GetAttr

    return cell.GetAttr()

  File "E:\MyProjects\temp\XLSGrid.py", line 1356, in GetAttr

    self.attr.IncRef()

  File "C:\Python25\lib\site-packages\wx-2.8-msw-unicode\wx\grid.py", line 529, in IncRef

    return _grid.GridCellAttr_IncRef(*args, **kwargs)

 TypeError: in method 'GridCellAttr_IncRef', expected argument 1 of type 'wxGridCellAttr *'

Or this one, in wxPython 2.9.2.1:

Traceback (most recent call last):

  File "E:\MyProjects\XLSGrid\xlsgrid.py", line 1553, in GetAttr

    return cell.GetAttr()

  File "E:\MyProjects\XLSGrid\xlsgrid.py", line 1356, in GetAttr

    self.attr.IncRef()

  File "c:\Python27\lib\site-packages\wx-2.9.2-msw\wx\_core.py", line 797, in IncRef

    return _core_.RefCounter_IncRef(*args, **kwargs)

TypeError: in method 'RefCounter_IncRef', expected argument 1 of type 'wxRefCounter *'

Isn't self.attr an instance of GridCellAttr?!?? I explicitly create it in the code above!!

2) `wx.grid.Grid` seems to completely redraw itself at every resize event, even if the cell content has not changed and it has not been damaged. This happens also in the "MegaGrid" sample in the wxPython demo. Why is that? I thought that the undamaged/unchanged cells should just be skipped from refreshing. I have tried to add wx.CLIP_CHILDREN and wx.NO_FULL_REPAINT_ON_RESIZE on the parent window, to no avail.

Enjoy, wxPython rules :-)

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

[Mike Driscoll]

Congrats Andrea! I can't wait to check it out!

- Mike

[Tobias Weber]

I already love it-

I am working on a project and had just started fiddling around doing sthg like this.... only more way more clumsy.
I will intensely play w/ it in the next days and am more than willing to provide feedback on whatever I am running into.

Thanks a million

:-)

Cheers,

S.

Am 08.08.11 23:06, schrieb Andrea Gavana:

--
To unsubscribe, send email to wxPython-user...@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

-- 
--------------------------------------------------
Tobias Weber
CEO

The ROG Corporation GmbH
Donaustaufer Str. 200
93059 Regensburg
Tel: +49 941 4610 57 55
Fax: +49 941 4610 57 56

www.roglink.com

Geschäftsführer: Tobias Weber
Registergericht: Amtsgericht Regensburg - HRB 8954
UStID DE225905250 - Steuer-Nr.184/59359
--------------------------------------------------

[Tobias Weber]

I already love it-

I am working on a project and had just started fiddling around doing sthg like this.... only more way more clumsy.
I will intensely play w/ it in the next days and am more than willing to provide feedback on whatever I am running into.

Thanks a million

:-)

Cheers,

S.

Am 08.08.11 23:06, schrieb Andrea Gavana:

Hi All,
    

--
To unsubscribe, send email to wxPython-user...@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

[pyt...@bdurham.com]

> Screenshots:

>

> (XLSGrid standalone)

> http://xoomer.virgilio.it/infinity77/Softwares/XLSGrid_1.png

> 

> (XLSGrid against Excel, same file)

> http://xoomer.virgilio.it/infinity77/Softwares/XLSGrid_3.png

 

Looks gorgeous Andrea!!!

 

Malcolm

[Robin Dunn]

> Or this one, in wxPython 2.9.2.1 <http://2.9.2.1>:

>
> Traceback (most recent call last):
> File "E:\MyProjects\XLSGrid\xlsgrid.py", line 1553, in GetAttr
> return cell.GetAttr()
> File "E:\MyProjects\XLSGrid\xlsgrid.py", line 1356, in GetAttr
> self.attr.IncRef()
> File "c:\Python27\lib\site-packages\wx-2.9.2-msw\wx\_core.py", line
> 797, in IncRef
> return _core_.RefCounter_IncRef(*args, **kwargs)
> TypeError: in method 'RefCounter_IncRef', expected argument 1 of type
> 'wxRefCounter *'
>
>
> Isn't self.attr an instance of GridCellAttr?!?? I explicitly create it
> in the code above!!

Adding a "print self.attr" will give you a bunch of these:

<wx.grid.GridCellAttr; proxy of wxPython wrapper for DELETED
GridCellAttr object! (The C++ object no longer exists.) >

So something is deleting the C++ object when you are not expecting it.
In this case it is the attr object itself as its refcount will be
reduced when the return value from GetAttr is used, so it will delete
itself because it is reaching zero. If you increment it an extra time
when you create it then that will let it know that you are keeping an
extra reference so you can use it again.

def GetAttr(self):
"""
Returns the attribute to use for this specific cell.

:returns: an instance of `wx.grid.GridCellAttr`.

"""
if self.attr is not None:

self.attr.IncRef()
return self.attr
else:
attr = gridlib.GridCellAttr()
attr.SetRenderer(XLSRenderer(self))

attr.SetSize(*self.size)
attr.SetOverflow(True)
self.attr = attr

self.attr.IncRef() # <--
return self.attr

>
>
> 2) `wx.grid.Grid` seems to completely redraw itself at every resize
> event, even if the cell content has not changed and it has not been
> damaged. This happens also in the "MegaGrid" sample in the wxPython
> demo. Why is that? I thought that the undamaged/unchanged cells should
> just be skipped from refreshing. I have tried to add wx.CLIP_CHILDREN
> and wx.NO_FULL_REPAINT_ON_RESIZE on the parent window, to no avail.

Yes it should, but I seem to recall something from way back about some
cases where not enough is being refreshed and so changes were added to
the grid to be more aggressive about refreshing. The grid window's
paint does try to calculate which cells intersect the update region and
then only call the renderer's Draw method for those cells, but if
something else is marking the whole window as invalid then the whole
thing will end up in the update region.

--
Robin Dunn
Software Craftsman
http://wxPython.org

[Andrea Gavana]

Hi Robin,

Thank you for this. I thought that IncRef() should be called only when re-using an existing instance of an attr (such as one stored in as a class member). I was really put off by this example:

http://www.java2s.com/Tutorial/Python/0380__wxPython/subclassPyGridTableBase.htm

Where the GetAttr method simply did this:

    def GetAttr(self, row, col, kind):
        attr = [self.even, self.odd][row % 2]
        attr.IncRef()
        return attr

 

2) `wx.grid.Grid` seems to completely redraw itself at every resize
event, even if the cell content has not changed and it has not been
damaged. This happens also in the "MegaGrid" sample in the wxPython
demo. Why is that? I thought that the undamaged/unchanged cells should
just be skipped from refreshing. I have tried to add wx.CLIP_CHILDREN
and wx.NO_FULL_REPAINT_ON_RESIZE on the parent window, to no avail.

Yes it should, but  I seem to recall something from way back about some cases where not enough is being refreshed and so changes were added to the grid to be more aggressive about refreshing.  The grid window's paint does try to calculate which cells intersect the update region and then only call the renderer's Draw method for those cells, but if something else is marking the whole window as invalid then the whole thing will end up in the update region.

I have discovered that wxPython 2.9.2.1 behaves much better than 2.8.11 on this issue. I have added this code in my XLSGrid class:

    def __init__(self, parent):

        gridlib.Grid.__init__(self, parent)

        # Skipped some initialization code

        self.paint_iter = 1

        self.GetGridWindow().Bind(wx.EVT_PAINT, self.OnPaint)

    def OnPaint(self, event):

        grid_window = event.GetEventObject()

        region = grid_window.GetUpdateRegion()

        rects = wx.RegionIterator(region)

        print "Paint event %d"%self.paint_iter

        print "Window size:", grid_window.GetSize()

        count = 0

        fmt_str = "Update rect %d: - width = %d , height = %d"

        while rects.HaveRects():

            print fmt_str%(count, rects.width, rects.height)

            rects.Next()

            count += 1

        print

        self.paint_iter += 1

        event.Skip()

And, on wxPython 2.8.11 (after the initial paint event which paints the whole window), every resize I make redraws the entire grid:

E:\MyProjects\XLSGrid>XLSGridDemo.py

Paint event 1

Window size: (819, 497)

Update rect 0: - width = 819 , height = 497

Paint event 2

Window size: (819, 498)

Update rect 0: - width = 819 , height = 498

Paint event 3

Window size: (819, 499)

Update rect 0: - width = 819 , height = 499

Paint event 4

Window size: (819, 500)

Update rect 0: - width = 819 , height = 500

Paint event 5

Window size: (819, 501)

Update rect 0: - width = 819 , height = 501

Paint event 6

Window size: (819, 502)

Update rect 0: - width = 819 , height = 502

Paint event 7

Window size: (819, 503)

Update rect 0: - width = 819 , height = 503

While on 2.9.2.1 it is much better:

E:\MyProjects\XLSGrid>c:\Python27\python.exe XLSGridDemo.py

Paint event 1

Window size: (819, 483)

Update rect 0: - width = 819 , height = 483

Paint event 2

Window size: (819, 484)

Update rect 0: - width = 819 , height = 1

Paint event 3

Window size: (819, 485)

Update rect 0: - width = 819 , height = 1

Paint event 4

Window size: (819, 486)

Update rect 0: - width = 819 , height = 1

Paint event 5

Window size: (819, 487)

Update rect 0: - width = 819 , height = 1

Paint event 6

Window size: (819, 488)

Update rect 0: - width = 819 , height = 1

Paint event 7

Window size: (819, 489)

Update rect 0: - width = 819 , height = 1

In fact, at least on Windows 7 and Vista, the flicker is pretty much gone.

Thank you again.

[Andrea Gavana]

Version 0.2 adds support for:

* Cell rich text (new in version 0.2): support for strings containing partial

  bold, italic and underlined text, change of font inside a string etc...

  Cells with rich text content can not be multi-line and they will not honour

  the `shrink-to-fit` and `wrapping` settings.

* Text subscripts/superscripts inside a single cell.

Both improvements are available only when using xlrd 0.7.2 (SVN). 

Enjoy.

[C M]

On Mon, Aug 8, 2011 at 5:06 PM, Andrea Gavana <andrea...@gmail.com> wrote:
> Hi All,
>
>     it's been a while since my last "announcement"... Anyway, I am happy to
> announce the birth of my latest child, XLSGrid.

Excellent as usual! It's always festive when a new AGWidget hits the list.

Two comments:

1) In the screenshots, it seems like the cells vertical and horizontal
lines are ahead by one pixel compared with the lines of the column and
row headers. It's not a big deal but maybe there is some easy way to
adjust that.

2) If it doesn't do it already, I would recommend you make it be able
to cut/copy/paste data to and from the clipboard with Ctr-X, -C, and
-V, as Excel does. This should be easy to do, and I got a recipe for
it online some where years back, and there is also the grid edit
mixin, here: http://sourceforge.net/projects/pywxgridedit/.
Depending on what you want to do I could try to add the patch from
what I have, but maybe the way I'm doing it is not the way you'd want.

Che

[jmfauth]

Hi Andrea,

Your application/class is suffering from a design flaw. It does
not take in account the coding of the characters.

The nice demo is perfectly reflecting the typical flow:

source --> processing --> destination

It happens the source is in unicode, the destination too.
The processing part is working in a "<type 'str'> style" or
let say, it does not care about the coding at all.

This way of working is not correct. It may luckily work fine
on your or some platforms. It is certainly not safe for
a general solution.

I did not really test. Just take a quick look. Code like this:

if not isinstance(s, str):
s = str(s)

can not work safely (s=unicode).

I'm not a xlrd user. I just came to this comment, when I saw
how xlrd works.

jmf

[Andrea Gavana]

Hi,

Both xlrd and XLSGrid work with unicode, you can see it directly from the screenshots (there are Arabic characters, Symbol strings, Windings glyphs). I guess you stopped looking at the code when you saw the "SplitThousands" method, which I have taken from:

http://code.activestate.com/recipes/498181-add-thousands-separator-commas-to-formatted-number/#c14

This method gets used only if pywin32 is not available. As far as I am concerned, I have pywin32 :-) . But I take your suggestion on board and modify the code that use those 2 offending lines. But from here to say that it doesn't work with unicode is a long shot, when I can easily demonstrate that both tools only process unicode strings without ever making any encoding/decoding. What gets slurped from xlrd/pywin32 is passed to wxPython directly.

[jmfauth]

On 11 août, 08:40, Andrea Gavana <andrea.gav...@gmail.com> wrote:

I did not say the application is not working. I'm just saying,
I'm not very comfortable with the coding of the characters.

Did you check with an another destination, like a wx-ansi build?
Understand a different coding.

I did it. There are some problems. Not because of "unicode/ansi",
but because of the lack of character coding handling. This is
what I'm calling a design flaw.

jmf

[Andrea Gavana]

Hi,

On 11 August 2011 09:46, jmfauth wrote:

On 11 août, 08:40, Andrea Gavana <andrea.gav...@gmail.com> wrote:

I did not say the application is not working. I'm just saying,
I'm not very comfortable with the coding of the characters.

Did you check with an another destination, like a wx-ansi build?
Understand a different coding.

No, as far as I am concerned wx-ansi is dead. 

 

I did it. There are some problems. Not because of "unicode/ansi",
but because of the lack of character coding handling. This is
what I'm calling a design flaw.

There is no need for this coding handling once everything you pass around is just unicode objects.

[jmfauth]

I see. It is a design choice. No objection.

---

I'm sticking with and favouring this model.

input --> processing --> output

with a pivot char coding for processing and an early cleaned
input encoding/decoding and a late cleaned output
encoding/decoding.

I does not mean I'm not a unicode defender.

jmf

[Martin Manns]

On Tue, 9 Aug 2011 00:06:17 +0300
Andrea Gavana <andrea...@gmail.com> wrote:

> it's been a while since my last "announcement"... Anyway, I am
> happy to announce the birth of my latest child, XLSGrid.

Very nice!

One issue:
The "shrink to fit" text shrinks o.k..
However, it does not expand again when extending the border again.
(Debian testing, Python 2.6.7, wxPython 2.8.10.1 (unicode), xlrd 0.6.1)

Cheers

Martin

[Andrea Gavana]

Hi Martin,

Thank you for the bug report, I have fixed it on my website.

 

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

==> Never *EVER* use RemovalGroup for your house removal. You'll regret it forever.
http://thedoomedcity.blogspot.com/2010/03/removal-group-nightmare.html <==

[Tim Roberts]

Mario Castro wrote:

around line 1967:

for j in xrange (ncols):
     if j in sheet.colinfo_map:
        current = sheet.colinfo_map [j]. width
     else:
        current = sheet.defcolwidth
    
     # # # ADDED
     if not current == None:
        col_width = int (round (float (default_width) * current/256.0))
     else:
        col_widht = 20 # Set a fixed size for cell
     # # # END

I'm interested by your use of "if not current == None".  Why not, for example:
    if current != None
Or, even better
    if current:

However, in this case I don't see how your explanation fits the code.  The value of "current" is not dependent on whether a cell is empty or not.  It's looking up the column number the column map, and if it's not there, it uses the default column width.  Have you set your column widths incorrectly?

-- 
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Robin Dunn]

On 10/3/12 9:51 AM, Tim Roberts wrote:

> I'm interested by your use of "if not current == None". Why not, for
> example:
> if current != None
> Or, even better
> if current:

Or if checking specifically for None is important, rather than just a
generic True/False value, then this is good and is marginally faster
than a == or != comparison:

if current is not None:

[Andrea Gavana]

Hi,

On 2 October 2012 17:38, Mario Castro wrote:
> Hi Andrea, I found a small bug (or I think so), if for some reason a cell
> contains a None value, (for example, I'm creating a document with xlwt from
> a database and the corresponding value is None), it is not possible to
> calculate the width of the cell and you get the following error:
>
>> TypeError: unsupported operand type (s) for *: 'float' and 'NoneType'
>
>
> My solution was as follows (xlsgrid.py):

>
> around line 1967:
>
>> for j in xrange (ncols):
>> if j in sheet.colinfo_map:
>> current = sheet.colinfo_map [j]. width
>> else:
>> current = sheet.defcolwidth
>>
>> # # # ADDED

>> if not current == None:

>> col_width = int (round (float (default_width) * current/256.0))
>> else:
>> col_widht = 20 # Set a fixed size for cell
>> # # # END
>

I am very curious to see why the previous code fails, as (in theory) a
column in an Excel spreadsheet has either a set value (that gets saved
into the colinfo_map dictionary when you size your column differently
than the default column width) *or* it has a default column width
(specified by the defcolwidth attribute). I have never seen a
situation in which the column width was "None".

Anyway, as Tim pointed out, this has nothing to do with the cell
content, only with column widths. I believe it's a bug in xlwt because
it doesn't set the default column width for the Excel spreadsheet. Is
it possible for you to send me (off-list) one of these Excel files?

In the end I think I'll be applying your workaround in this form:

if current is not None:

col_width = int (round (float (default_width) * current/256.0))
else:
col_widht = 20 # Set a fixed size for cell

However, I have just moved to a new house and I wont have internet
connection for some time, and I can't use SVN from work. Maybe someone
in our pool of kind developers (Robin, Kevin, Cody, Chris, etc...)
with SVN write access could apply that modification for me; otherwise
you will have to wait a week or two for me to be back to speed.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

if mention_platform_and_version() and include_sample_app():
send_message(email)
else:
install_malware()
erase_hard_drives()
# ------------------------------------------------------------- #

[Mike Driscoll]

Hi Andrea,

However, I have just moved to a new house and I wont have internet
connection for some time, and I can't use SVN from work. Maybe someone
in our pool of kind developers (Robin, Kevin, Cody, Chris, etc...)
with SVN write access could apply that modification for me; otherwise
you will have to wait a week or two for me to be back to speed.


Andrea.

Wow! You moved again? Congrats, I think. I hope your move went better than the last one.

- Mike

[Andrea Gavana]

I did move home, but stayed in Copenhagen :-) . It went much better
than the last one, thanks for asking :-D :-D

[Robin Dunn]

On 10/3/12 10:58 PM, Andrea Gavana wrote:
> Anyway, as Tim pointed out, this has nothing to do with the cell
> content, only with column widths. I believe it's a bug in xlwt because
> it doesn't set the default column width for the Excel spreadsheet. Is
> it possible for you to send me (off-list) one of these Excel files?
>
> In the end I think I'll be applying your workaround in this form:
>
> if current is not None:
> col_width = int (round (float (default_width) * current/256.0))
> else:
> col_widht = 20 # Set a fixed size for cell
>
> However, I have just moved to a new house and I wont have internet
> connection for some time, and I can't use SVN from work. Maybe someone
> in our pool of kind developers (Robin, Kevin, Cody, Chris, etc...)
> with SVN write access could apply that modification for me; otherwise
> you will have to wait a week or two for me to be back to speed.

Done, minus the typo.

http://trac.wxwidgets.org/changeset/72644/wxPython/3rdParty/AGW

[Mario Castro]

Hello, sorry for the delay but lately I've had trouble connecting to the Internet.

The point is that I am generating (using xlwt) an Excel document, from the data loaded in a form and stored in a SQLite database, to then load this document in my application using XLSGrid.

Queries to the database, return, in some fields a None value (for example, a date that is not loaded in the form and get a default None value in the database), and are those fields that cause the error.

I assume that indeed is a bug in xlwt (which I have not checked), which did not consider the nature of the document created, since it is very different to create a spreadsheet using OpenOffice, Excel or similar, to create it in a rather more "Handcrafted" way.

The Excel File is in : https://docs.google.com/open?id=0B6iCxVHg0ejlQk9DSG1ZZ2dWeDA

And thank you very much for the suggestions and corrections regarding the conditional, sometimes I have a tangled mind, so sometimes I make some strange errors.