If (!(iEndRowIndex mc.EndRowIndex || iEndColumnIndex mc.EndColumnIndex)) And “StartColumnIndex” mean the left-most column of the merged cell, and “EndColumnIndex” mean the right-most column of the merged cell. To make it easier, the variables with “StartRowIndex” mean the top row of the merged cell, “EndRowIndex” mean the bottom row of the merged cell. So what’s the programmatic way to check? You’d be surprised at the simplicity. The vertical lines x=5, x=6 or x=8 also fit the bill. This is where the “whole number” condition comes in). Or even y=7 (note that the line can “touch” one of the merged cells, but not both. The horizontal line of 5 fits the bill, or the line y=5 if you want to be mathematical about it (but y goes from negative to positive downwards instead of the usual Cartesian y). Suppose we want to check if this merge cell overlaps: top-left corner at row 7 column 8, bottom-right corner at row 10 column 10.
This merged cell has the top-left corner at row 1 column 1, and the bottom-right corner at row 3 column 4. Let’s say our existing set of merged cells only has one entry. The column index uses alphabets and is in base-26. Excel uses cell references that are in the A1 format, which means row 3 column 4 becomes “D3”. So in our case, as long as you can find one horizontal line or one vertical line that separates the 2 merged cells we’re checking, then the 2 merged cells are separate. And even better, you can always find a subset of solutions of those separating axes that are either horizontal or vertical. And since they map strictly to a 2D rectangular grid, the separating axis is a line. Since the 4 end points are in whole numbers, line boundaries can be easily calculated (it’s easy to check if something is =8 for example). Since the merged cells are rectangular, they’re also convex (I’m not going to explain why, just trust me). The (merged) cells map strictly to a 2D rectangular grid.The 4 end points (top-left, top-right, bottom-left, bottom-right) of a merged cell are in whole numbers.
(yes I’m a mathematician…) I’ll leave it to you to do your own reading.īut for our purposes, how do we check if that rectangle of Excel cells we want to merge won’t overlap with any existing merged cells? We have these conditions that make our lives easier: There are some conditions to be fulfilled, such as the objects being convex and disjoint and whatever. Another example is when you’re given two 2D objects, and if you can find one line (which is 1D) that separates them, then the 2D objects are not overlapping. From what I understand, given two N-dimensional thingies, if you can find one (N-1)-dimensional hyperplane that separates those two thingies, then those two thingies are separate (or not overlapping).įor example, given two 3D objects, if you can find one 2D plane that separates them, then the 3D objects are not overlapping. Yes, the type of collision detection used in games so you don’t walk through walls and stuff.Īnd thus I learnt a new mathematical theorem: the separating axis theorem (or hyperplane separation theorem). Can’t remember what I was there for, but the answer page wasn’t about Excel or spreadsheets. The inkling of an idea was formed when I visited StackOverflow.
#Merging cells in excel definition software
Well, that was the problem I faced while writing my spreadsheet library software ( check out SpreadsheetLight here!). So how does Excel ensure that the cells you want to merge don’t overlap any existing merged cells? How do you check programmatically that the cells you want to merge won’t overlap any existing merged cells?
0 kommentar(er)
