[archive] Active X Grid Control

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

I am not going to comment on the grid, apart of that many uses it. But I would like to say something about this:

My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

I am pretty sure Sharpgrid can take what ever you throw at it, but you should not do this. This is why paged grids are invented.
If you load a grid with tens of thousands of lines, it will inevitably take a long time to load the grid, no matter what grid it is. This time will by the user be experienced as annoying and thus lead to a negative experience of your application. On top of it, I seriously doubt that anyone will want to browse through tens of thousands of rows to find the one they are interested in. For such, you should provide an entry field where data can be inserted to limit the scope.
You should load a limited amount, and add/replace in the grid as need raise.

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

Hi Rebeka,
as always Gisle's comment is significant: amount of data to be loaded is a point to be exactly focused for evaluate an investement for a new component. One more feature to be considered is: AcitveX are locally run, so they must be installed locally on client. With Acu grid you just deploy .cob module on server and it's done! The fact that ActiveX is client side and the amount of data you must load on it so much relevant 'cos in a thin client environment: it generates data network traffic that an Acu grid doesen't.
By the way in some programs we use ComponentOne VsFlexGrid: really flexible and full of capabilities, but only in particoular programs where the user can need to do, as You noticed, what Acu integrated grids can't do or are not so programmer's friendly to implement. They can sort columns, search in rows, get buttons embedded onto cells and more other things as indent rows for a tree view father-child relationship, moreover they can export directly to an .xls file and more features. One more suggestion if you're interested on them take the idea of buying the complete activeX and .Net suite with a bunch more money they can get a ton of well done components for more than a Development environment.
Hope this helps, bye Giovanni.

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

Hi Rebeka,
as always Gisle's comment is significant: amount of data to be loaded is a point to be exactly focused for evaluate an investement for a new component. One more feature to be considered is: AcitveX are locally run, so they must be installed locally on client. With Acu grid you just deploy .cob module on server and it's done! The fact that ActiveX is client side and the amount of data you must load on it so much relevant 'cos in a thin client environment: it generates data network traffic that an Acu grid doesen't.
By the way in some programs we use ComponentOne VsFlexGrid: really flexible and full of capabilities, but only in particoular programs where the user can need to do, as You noticed, what Acu integrated grids can't do or are not so programmer's friendly to implement. They can sort columns, search in rows, get buttons embedded onto cells and more other things as indent rows for a tree view father-child relationship, moreover they can export directly to an .xls file and more features. One more suggestion if you're interested on them take the idea of buying the complete activeX and .Net suite with a bunch more money they can get a ton of well done components for more than a Development environment.
Hope this helps, bye Giovanni.

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

Hi Rebeka,
as always Gisle's comment is significant: amount of data to be loaded is a point to be exactly focused for evaluate an investement for a new component. One more feature to be considered is: AcitveX are locally run, so they must be installed locally on client. With Acu grid you just deploy .cob module on server and it's done! The fact that ActiveX is client side and the amount of data you must load on it so much relevant 'cos in a thin client environment: it generates data network traffic that an Acu grid doesen't.
By the way in some programs we use ComponentOne VsFlexGrid: really flexible and full of capabilities, but only in particoular programs where the user can need to do, as You noticed, what Acu integrated grids can't do or are not so programmer's friendly to implement. They can sort columns, search in rows, get buttons embedded onto cells and more other things as indent rows for a tree view father-child relationship, moreover they can export directly to an .xls file and more features. One more suggestion if you're interested on them take the idea of buying the complete activeX and .Net suite with a bunch more money they can get a ton of well done components for more than a Development environment.
Hope this helps, bye Giovanni.

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

I am not going to comment on the grid, apart of that many uses it. But I would like to say something about this:

I am pretty sure Sharpgrid can take what ever you throw at it, but you should not do this. This is why paged grids are invented.
If you load a grid with tens of thousands of lines, it will inevitably take a long time to load the grid, no matter what grid it is. This time will by the user be experienced as annoying and thus lead to a negative experience of your application. On top of it, I seriously doubt that anyone will want to browse through tens of thousands of rows to find the one they are interested in. For such, you should provide an entry field where data can be inserted to limit the scope.
You should load a limited amount, and add/replace in the grid as need raise.

We do use the paged grids and paged list boxes now and provide various sort methods and filters -- it's just that even with all of these options, our customers want to hide columns, change the sort order, and dump to Excel. That is the biggest reason we are considering the others. I will keep this in mind though. We do have routines that load our paged list boxes and grids in threads so that the user can begin browsing the data while it is still loading - versus having to wait for the whole thing to load. And that will be a big consideration for us. Thanks.

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

We have been using #Grid since 2002 completely throughout our system. In fact, I think we helped it become popular within the Acucorp community. ;-)

The reasons that Rebekah gave are the same reasons we chose #Grid. We have implemented all of those features and more. I love #Grid and would recommend it to anyone. The support is great. The object model is easy to understand and program with and the product is feature rich. #Grid has become a major "feature" of our product and our users love the functionality.

There are definitely some things to consider, however:

1. Load speed will vary depending on how you choose to implement. And regardless of how you do it, it probably won't be as fast as the Acucorp grid. To us, the features we get from #Grid make the performance hit worth it. We are loading the grid via an XML file.

2. We "save layouts" so that users can control how the grid appears. This includes how wide columns are as well as most any other cosmetic features. This is also done via an XML file.

3. We spent a LOT of development on writing our own "paged grid" code. #Grid doesn't directly support paging, but it's so flexible you can do it. As is mentioned in earlier posts, this would be an essential feature to have.

4. We do use the Export to Excel option and it's pretty seamless. The only limitation we've found on that so far is that there is no way to get a field formatted as a date to Excel.

5. Only other issue I can think of is that they do not automatically format dates and numbers. This automatic formatting only works in VB (because they use something in VB to do this, I guess). For other develoment environments, they use an Event to format. This didn't work well for us and we ended up coding another solution to this. If everything is in the grid as alpha, there's no big deal. The reason for having numbers and dates in the grid is so it will sort properly.

Anyways, feel free to contact me if you have any questions. If it has to do with #Grid, I've pretty much encountered it more than likely...

Rob

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

Rob, thank you for your reply. Is there a benefit to loading the grid via XML?

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

Rob, thank you for your reply. Is there a benefit to loading the grid via XML?

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

Rob, thank you for your reply. Is there a benefit to loading the grid via XML?

[Migrated content. Thread originally posted on 23 August 2007]

We are using the AcuCobol grid control currently, but are going to be adding several new grids into our application where our customers will expect to be able to resize columns, sort columns, and delete columns. Several weeks back I had a problem with a grid and the AcuCorp technical support suggested I might try Sharp Grid and I have seen that referenced several times in the forums. I downloaded the evaluation and reference manual and was able to get a simple grid up and going with Sharp Grid in a matter of minutes. Before I continue and commit to using Sharp Grid, I wanted to post and ask those of you currently using Sharp Grid a few questions. This will be a big decision for us and we want to make the right decision.

How long have you used Sharp Grid?

Are there any restrictions I should be aware of? My main concern is with the quantity of data I can send to a single grid. I did my sample with the comma seperated fields. I am not worried about the columns, as I am the rows. I will be using this for invoice history which can be extremely large. Is there a limit to the number of rows a single grid can hold?

Is there anything you don't like about the Sharp Grid or that AcuCobol gives you that the Sharp Grid doesn't? It seems to me to able to do a lot of nice funtions relatively easily.

Can you dump directly from the grid to Excel? And, what about saving the column sizing - we do that now with our AcuCobol grids - can Sharp Grid pass back the column widths so you can load them again the next time?

Any help is greatly appreciated. The product looks great to me -- but again, I would like some feedback from those of you using it now.

TIA!

Rebekah, Yes. The benefit is that it doesn't matter what order the fields are. So if the user changes the order of fields or removes some, it will still work (whereas this is more complicated with comma delimited or other methods).