KGunder
2018-06-06T15:54:35Z
Hi Igor,

is there an easy way to paste data (e.g. from Excel) from the clipboard to iGrid ?
e.g. .FillFromClipboard

Best regards

Klaus
Igor/10Tec
2018-06-07T05:08:00Z
You can paste cells copied from Excel into iGrid with CTRL+V. If we talk about the ability to imitate this operation from code, the following statement does this:

iGrid1.DoKeyboardCommand vbKeyV, vbCtrlMask

(fore more info, see the topic 'Code Equivalents of User Actions' in the help file)

This statement will insert the copied cells into the cell rectangle with the top-left corner located in the current cell. Thus, even if you need to insert the copied cells into any cell, you make it current first with the SetCurCell method and then issue the statement I showed above.

Is it what you expected?
KGunder
2018-06-07T07:48:13Z
yes, I have found the DoKeyboardCommand, but when I paste Excel Data, I have to know how many cols and rows the data contains.
Currently I do

    .AddCol lCount:=65535    ' ???
    .AddRow lCount:=63535    ' ???
    .DoKeyboardCommand vbKeyV, vbCtrlMask
But then I have a lot of empty rows and columns...
Igor/10Tec
2018-06-07T15:34:17Z
So your problem is to know how many rows and columns will be pasted and then add the corresponding number of rows and columns to iGrid to accommodate all pasted cells if required, right?

The 'Copy/paste Functionality' topic from the iGrid CHM explains what iGrid does if the number of columns and rows are not enough for the pasted data:

Quote:

If virtual mode is on, iGrid adds the required rows automatically while pasting data and the alert described above isn't displayed. However, the column set isn't extended this way in virtual mode, and the user will see the alert if the available columns aren't enough to paste all data even if virtual mode is on.



As I remember, one of the developers using iGrid reported a similar problem, and we implemented this solution. Perhaps, it was not a good universal solution, but it was the wisest and "hot" solution for a particular version of iGrid as we could not break binary compatibility by adding new members to iGrid to control this behavior. The fact is that adding column dynamically on CTRL+V is not the thing required in most apps, though adding rows dynamically at pasting is good in most cases.

I can think about changing the behavior of iGrid to make it smarter and allow automatic creation of columns and rows to accommodate all pasted data. These could be two Boolean properties like AllowAutoAddColumnsOnPaste/AllowAutoAddRowsOnPaste that enable this mode for columns/rows. Or it can be an event named, say, PasteAddRowsColumns that tells the developer how many rows/columns will be added to iGrid and allows the developer to enable this action with the standard bDoDefault parameter.

What do you think? I'd like to know your opinion to implement a solution that will help you and other developers.
KGunder
2018-06-10T21:36:04Z
Hi Igor,

why bother the user with throwing an error message about too few rows/columns, what is the use case for this?
Shouldn't it be the default behaviour to add the required rows/columns on Paste ? (So we wouldn't need those two Boolean properties)
But it would be nice to have two events: BeforePaste(df as DataFormats.Format, byref bCancel as Boolean) and AfterPaste()
In BeforePaste I could check the dataformat of the clipboard and maybe ask the user if he really wants to insert the data
In AfterPaste I could check the inserted data and maybe adjust to the new MaxRows/MaxCols

Best regards
Klaus
Igor/10Tec
2018-06-11T09:03:21Z
In most cases the developer defines the "hard" column set and does not expect that the user can change it by adding new columns. If we allow the user to paste data and extend the grid automatically to accommodate all pasted data, there is a high probability that the user will add new columns to the grid and change the structure of the grid - which may lead to improper functioning of the app.

To process all these situations, I think, iGrid should provide the developer with the ability to allow the automatic adding of columns/rows while pasting data. However, this functionality must be disabled by default - which, as I explained, is the expected behavior of iGrid in most cases. To enable this thing, iGrid can raise an event named, say, BeforePaste with the following arguments:

BeforePaste(ByVal lColsToAdd As Long, ByVal lRowsToAdd As Long, ByRef bDoDefault As Boolean)

Note that in contrast to many other events providing the bDoDefault parameter, this parameter will be set to False by default. If iGrid needs more columns/rows to accommodate the pasted data, lColsToAdd and/or lRowsToAdd will be greater than 0. The developer can analyze these values in the event handler and allow columns/rows addition explicitly by setting bDoDefault to True, or prohibit this action by doing nothing or even display a warning telling why the data can't be pasted.

As an alternative, we can provide an enumeration with the following 3 values instead of bDoDefault:

  • Do nothing
  • Paste data, but clip them if column/rows are not enough
  • Paste data and extend the grid if required


One more alternative - to provide two Boolean parameters passed by reference that will allow to enable adding columns and rows separately:

BeforePaste(ByVal lColsToAdd As Long, ByVal lRowsToAdd As Long, _
   ByRef bAddCols As Boolean, ByRef bAddRows As Boolean)

The idea is that the developer may allow adding rows dynamically on CTRL+V, but not adding columns.

As one more feature, we can add the bDoDefault parameter to the last event signature, but this parameter will enable/disable pasting data as a whole operation:

BeforePaste(ByVal lColsToAdd As Long, ByVal lRowsToAdd As Long, _
   ByRef bDoDefault As Boolean, ByRef bAddCols As Boolean, ByRef bAddRows As Boolean)

Having this "classical" iGrid's bDoDefault parameter and bAddCols/bAddRows, you will be able to implement any behavior needed at pasting data - not to paste data at all, paste data but do not enlarge iGrid, paste data and add only rows on-the-fly, and so on.

How about that?
Igor/10Tec
2018-06-11T10:53:48Z
As for adding one more parameter like 'df as DataFormats.Format' you suggested, it may be a bad idea to use a specific object type as the base type as it may be supported only in one development environment. We need to support several major development environments (VB6, MS Office VBA, some VBA-based CADs, etc.), and using a type say from MS Office VBA will force developers in other environments to add references to the library that defines/implement that type. As I can judge from my experience, there can be compatibility problems and iGrid may simply stop working in some environments.

Do you really need to analyze the format of pasted data before pasting? What other parameters of the pasted data you may need to know before pasting them into iGrid?
KGunder
2018-06-20T14:34:29Z
Hi Igor,

Originally Posted by: Igor/10Tec 



As one more feature, we can add the bDoDefault parameter to the last event signature, but this parameter will enable/disable pasting data as a whole operation:

BeforePaste(ByVal lColsToAdd As Long, ByVal lRowsToAdd As Long, _
   ByRef bDoDefault As Boolean, ByRef bAddCols As Boolean, ByRef bAddRows As Boolean)

Having this "classical" iGrid's bDoDefault parameter and bAddCols/bAddRows, you will be able to implement any behavior needed at pasting data - not to paste data at all, paste data but do not enlarge iGrid, paste data and add only rows on-the-fly, and so on.

How about that?



Thats great !
Igor/10Tec
2018-11-26T16:34:46Z
The feature we discussed here has been implemented in iGrid 7.0 released today.