Home » Eclipse Projects » DTP » Reusing the server explorer in a ContainerCheckedTreeViewer
| Reusing the server explorer in a ContainerCheckedTreeViewer [message #47985] |
Fri, 01 August 2008 03:01  |
Eclipse User |
|
|
|
Originally posted by: philippe.girard.gmail.com
Hi,
I am interested in becoming a contributor to the Datatools project. I'm a
DBA and I am very much impressed with what has been done so far and I want
to add features to the project.
One of these feature is a project nature for database. Instead of having
to create a generic project this would be a dedicated project nature for
databases.
I am currently developping the New Project wizard and on one of the wizard
page I would like to display the SQL Model from the selected connection
profile (I reused the ProfileSelectionComposite for selecting the
connection) in a ContainerCheckedTreeViewer so that the user could select
the database objects to export as DDL statement.
Of course to fill the ContainerCheckedTreeViewer I need a ContentProvider
and a LabelProvider and I have been trying to reuse the existing
SQLModelContentProviderExtension and SQLModelLabelProviderExtension. But I
have not met much success so far. I get the first level built and then
thrown an exception.
It looks like the existing classes are too tied to a CommonViewer class to
be reused in a ContainerCheckedTreeViewer, but I might be mistaken and
simply overlooking something.
Anybody know if reusing any of the existing Content and Label provider
could be reused in such a fashion ?
Should I develop my own Content and Label provider to fill a
ContainerCheckedTreeViewer (and then worry about having to support varying
ContentExtensions...) ?
Any pointer would be much appreciated...
BTW the source code is hosted at sourceforge.net under the dtp-dbproject.
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #48015 is a reply to message #47985] |
Fri, 01 August 2008 14:22  |
| Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
Hi Philippe...
That sounds great! We're always on the lookout for more help. :)
Do you have a use case for this type of functionality? (I can see some uses,
but I'm curious what you see as the main goal of going this route.)
All of the existing content and label providers that are hosted in the DSE
are pretty focused on the Common Navigator Framework. The reason for that
was that it was easy to provide additional extensions via separate plug-ins
to contribute various levels of the SQL model hierarchy, etc.
That said, you should be able to do this by massaging some of the existing
code. If you use the ProfileSelectionDialogPage and build your own
ProfileSelectionComposite, you can change the styles that are passed to the
CommonViewer when it's created.
The doCreateControl() method (protected void doCreateControl(Composite
content, boolean flag, boolean multiSelect)) can be changed to provide your
own checkbox styles (SWT.CHECK) and you should be able to add a selection
listener to the tree for SWT.CHECK events...
if(event.detail == SWT.CHECK)
If that doesn't work, give me a holler and I'll try and come up with an
example. Hope that helps!--Fitz
"Philippe Girard" <philippe.girard@gmail.com> wrote in message
news:4f046d24f139b292d0173b3516a470f5$1@www.eclipse.org...
> Hi,
>
> I am interested in becoming a contributor to the Datatools project. I'm a
> DBA and I am very much impressed with what has been done so far and I want
> to add features to the project.
>
> One of these feature is a project nature for database. Instead of having
> to create a generic project this would be a dedicated project nature for
> databases.
>
> I am currently developping the New Project wizard and on one of the wizard
> page I would like to display the SQL Model from the selected connection
> profile (I reused the ProfileSelectionComposite for selecting the
> connection) in a ContainerCheckedTreeViewer so that the user could select
> the database objects to export as DDL statement.
>
> Of course to fill the ContainerCheckedTreeViewer I need a ContentProvider
> and a LabelProvider and I have been trying to reuse the existing
> SQLModelContentProviderExtension and SQLModelLabelProviderExtension. But I
> have not met much success so far. I get the first level built and then
> thrown an exception.
>
> It looks like the existing classes are too tied to a CommonViewer class to
> be reused in a ContainerCheckedTreeViewer, but I might be mistaken and
> simply overlooking something.
> Anybody know if reusing any of the existing Content and Label provider
> could be reused in such a fashion ?
> Should I develop my own Content and Label provider to fill a
> ContainerCheckedTreeViewer (and then worry about having to support varying
> ContentExtensions...) ?
>
> Any pointer would be much appreciated...
>
> BTW the source code is hosted at sourceforge.net under the dtp-dbproject.
>
>
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #48045 is a reply to message #48015] |
Sat, 02 August 2008 02:31 |
| Eclipse User |
|
|
|
Originally posted by: philippe.girard.gmail.com
Brian Fitzpatrick wrote:
> Hi Philippe...
> That sounds great! We're always on the lookout for more help. :)
> Do you have a use case for this type of functionality? (I can see some uses,
> but I'm curious what you see as the main goal of going this route.)
I didn't write a formal use case for it, but I could provide one if you'd
like. But as far as how the feature would be used I was thinking along the
following lines:
For a new project the user would select a connection profile and the
database objects to export. The databases object DDL statement would then
be generated to individual files and stored in the project hierarchy which
would be similar the SQL Model hierarchy (Tables, views and routines
folders split repeated for each schemas).
Once created the project could then be put in a version control system
(supplied by eclipse). This is actually one of my main goal: to provide a
easy way of exporting the database objects and then be able to put it
under version control.
The project structures would also be used to stored deployment scripts,
SQL Test case, data generation plan, etc... Any scripts that would be
related to a project.
It would also be possible to import new object to an existing project.
I also want to add a deploy functionality. This would then deploy the
project to a given connection profile.
In a development scenario, the developer would check out the project, make
his modification, deploy it to test.
Of course while the deploy functionality is probably good enough for
dev/testing it is ill suited for production deployment (especially for
tables modification). This is why the next feature I want to develop will
be a schema compare... But one feature at a time ;-)
Also if you see anything else that could be added to the dbproject tool
then let me know. I am mostly developing a tool that I would use, but I am
very much interested in what other people other people would like in a
project functionality.
> All of the existing content and label providers that are hosted in the DSE
> are pretty focused on the Common Navigator Framework. The reason for that
> was that it was easy to provide additional extensions via separate plug-ins
> to contribute various levels of the SQL model hierarchy, etc.
> That said, you should be able to do this by massaging some of the existing
> code. If you use the ProfileSelectionDialogPage and build your own
> ProfileSelectionComposite, you can change the styles that are passed to the
> CommonViewer when it's created.
> The doCreateControl() method (protected void doCreateControl(Composite
> content, boolean flag, boolean multiSelect)) can be changed to provide your
> own checkbox styles (SWT.CHECK) and you should be able to add a selection
> listener to the tree for SWT.CHECK events...
> if(event.detail == SWT.CHECK)
> If that doesn't work, give me a holler and I'll try and come up with an
> example. Hope that helps!--Fitz
Thanks for the tips. I hadn't realized that I could supply the check style
to the common viewer. I am thinking that I could probably extend the
common viewer and add it the ContainerCheckedTreeViewer code for handling
the checkboxes.
This brings me to wonder if it is be possible to limit the Common
Navigator to display only the Schemas section ? Since in this case that is
the only thing I would need to display to the user.
|
|
| |
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #48105 is a reply to message #48045] |
Mon, 04 August 2008 13:49 |
| Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
And integrating with the version control system is a very interesting idea.
I think a number of developers might be interested in that, as it would be a
way to share database tests, scripts, and whatever else they wanted to
associate with a given connection profile.
My only concern would be that it may be too focused on databases (though
that's what your use case requires). If we were going to do something
similar in DTP, we woul most likely abstract it to handle any kind of
connection profile type and then specialize that for database connection
profiles. ODA is a type of profile that isn't necessarily database-related,
so it would benefit from having the more abstracted way of looking at
things.
Any thoughts on that?
--Fitz
"Philippe Girard" <philippe.girard@gmail.com> wrote in message
news:1ea032669e1c85196159cb7294e6ba16$1@www.eclipse.org...
> Brian Fitzpatrick wrote:
>
>> Hi Philippe...
>
>> That sounds great! We're always on the lookout for more help. :)
>
>> Do you have a use case for this type of functionality? (I can see some
>> uses, but I'm curious what you see as the main goal of going this route.)
>
> I didn't write a formal use case for it, but I could provide one if you'd
> like. But as far as how the feature would be used I was thinking along the
> following lines:
>
> For a new project the user would select a connection profile and the
> database objects to export. The databases object DDL statement would then
> be generated to individual files and stored in the project hierarchy which
> would be similar the SQL Model hierarchy (Tables, views and routines
> folders split repeated for each schemas).
> Once created the project could then be put in a version control system
> (supplied by eclipse). This is actually one of my main goal: to provide a
> easy way of exporting the database objects and then be able to put it
> under version control.
>
> The project structures would also be used to stored deployment scripts,
> SQL Test case, data generation plan, etc... Any scripts that would be
> related to a project.
>
> It would also be possible to import new object to an existing project.
> I also want to add a deploy functionality. This would then deploy the
> project to a given connection profile.
>
> In a development scenario, the developer would check out the project, make
> his modification, deploy it to test.
>
> Of course while the deploy functionality is probably good enough for
> dev/testing it is ill suited for production deployment (especially for
> tables modification). This is why the next feature I want to develop will
> be a schema compare... But one feature at a time ;-)
>
> Also if you see anything else that could be added to the dbproject tool
> then let me know. I am mostly developing a tool that I would use, but I am
> very much interested in what other people other people would like in a
> project functionality.
>
>> All of the existing content and label providers that are hosted in the
>> DSE are pretty focused on the Common Navigator Framework. The reason for
>> that was that it was easy to provide additional extensions via separate
>> plug-ins to contribute various levels of the SQL model hierarchy, etc.
>
>> That said, you should be able to do this by massaging some of the
>> existing code. If you use the ProfileSelectionDialogPage and build your
>> own ProfileSelectionComposite, you can change the styles that are passed
>> to the CommonViewer when it's created.
>
>> The doCreateControl() method (protected void doCreateControl(Composite
>> content, boolean flag, boolean multiSelect)) can be changed to provide
>> your own checkbox styles (SWT.CHECK) and you should be able to add a
>> selection listener to the tree for SWT.CHECK events...
>> if(event.detail == SWT.CHECK)
>> If that doesn't work, give me a holler and I'll try and come up with an
>> example. Hope that helps!--Fitz
>
> Thanks for the tips. I hadn't realized that I could supply the check style
> to the common viewer. I am thinking that I could probably extend the
> common viewer and add it the ContainerCheckedTreeViewer code for handling
> the checkboxes.
>
> This brings me to wonder if it is be possible to limit the Common
> Navigator to display only the Schemas section ? Since in this case that is
> the only thing I would need to display to the user.
>
>
>
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #48251 is a reply to message #48105] |
Wed, 06 August 2008 01:12 |
| Eclipse User |
|
|
|
Originally posted by: philippe.girard.gmail.com
> My only concern would be that it may be too focused on databases (though
> that's what your use case requires). If we were going to do something
> similar in DTP, we woul most likely abstract it to handle any kind of
> connection profile type and then specialize that for database connection
> profiles. ODA is a type of profile that isn't necessarily database-related,
> so it would benefit from having the more abstracted way of looking at
> things.
I agree with you that abstracting it for any kind of connection profile is
best. Although I don't know much about ODA, I will research it.
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #48899 is a reply to message #48075] |
Thu, 14 August 2008 03:12 |
| Eclipse User |
|
|
|
Originally posted by: philippe.girard.gmail.com
Brian Fitzpatrick wrote:
> You bet. You can add a new ViewerFilter to the CommonViewer that filters out
> whatever you want, just like a normal viewer.
> "Philippe Girard" <philippe.girard@gmail.com> wrote in message
> news:1ea032669e1c85196159cb7294e6ba16$1@www.eclipse.org...
>> This brings me to wonder if it is be possible to limit the Common
>> Navigator to display only the Schemas section ? Since in this case that is
>> the only thing I would need to display to the user.
>>
>>
>>
Following up on this. I used the Common Navigator and realized that the
tree is not built until the user expands the nodes to get to the sql
objects. So to be able to use it I would need to build the whole tree
before presenting it to the user. I checked and while there is a collapse
all action. I could not find an expand all action.
I was wondering if such a functionality (building the whole sql model tree
in the common navigator viewer) exists that I missed or if I would have to
code such a functionality.
Again, any pointer than you might have is much appreciated.
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #48929 is a reply to message #48899] |
Thu, 14 August 2008 15:30 |
| Eclipse User |
|
|
|
Originally posted by: brianf.sybase.com
Hey Philippe...
Glad you're making some progress!
As for Expand All, we used to have an Expand All action in DTP 1.5. If you
take a look in the DataTools CVS repository, you can find it at:
> HEAD/org.eclipse.datatools.connectivity/R1.5/org.eclipse.dat atools.connectivity.ui.dse/src/org/eclipse/datatools/connect ivity/ui/dse/actions/ExpandAllActionDelegate.java
As a word of caution, this was removed because it is UGLY... It's very
painful to trigger the tree to expand all of these levels down the line, so
you'd need to be careful in how you used it. It's very time consuming (and
process/threads), but it was the best of a bad solution.
It may not play well in 1.6 without some work, but it should get you
started.
Let me know if you have further questions.
--Fitz
"Philippe Girard" <philippe.girard@gmail.com> wrote in message
news:afc137a6ac599675eacbb00511e6c408$1@www.eclipse.org...
> Following up on this. I used the Common Navigator and realized that the
> tree is not built until the user expands the nodes to get to the sql
> objects. So to be able to use it I would need to build the whole tree
> before presenting it to the user. I checked and while there is a collapse
> all action. I could not find an expand all action.
>
> I was wondering if such a functionality (building the whole sql model tree
> in the common navigator viewer) exists that I missed or if I would have to
> code such a functionality.
>
> Again, any pointer than you might have is much appreciated.
>
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #592350 is a reply to message #47985] |
Fri, 01 August 2008 14:22 |
 Brian Fitzpatrick
Messages: 500
Registered: July 2009 |
Senior Member |
|
|
Hi Philippe...
That sounds great! We're always on the lookout for more help. :)
Do you have a use case for this type of functionality? (I can see some uses,
but I'm curious what you see as the main goal of going this route.)
All of the existing content and label providers that are hosted in the DSE
are pretty focused on the Common Navigator Framework. The reason for that
was that it was easy to provide additional extensions via separate plug-ins
to contribute various levels of the SQL model hierarchy, etc.
That said, you should be able to do this by massaging some of the existing
code. If you use the ProfileSelectionDialogPage and build your own
ProfileSelectionComposite, you can change the styles that are passed to the
CommonViewer when it's created.
The doCreateControl() method (protected void doCreateControl(Composite
content, boolean flag, boolean multiSelect)) can be changed to provide your
own checkbox styles (SWT.CHECK) and you should be able to add a selection
listener to the tree for SWT.CHECK events...
if(event.detail == SWT.CHECK)
If that doesn't work, give me a holler and I'll try and come up with an
example. Hope that helps!--Fitz
"Philippe Girard" <philippe.girard@gmail.com> wrote in message
news:4f046d24f139b292d0173b3516a470f5$1@www.eclipse.org...
> Hi,
>
> I am interested in becoming a contributor to the Datatools project. I'm a
> DBA and I am very much impressed with what has been done so far and I want
> to add features to the project.
>
> One of these feature is a project nature for database. Instead of having
> to create a generic project this would be a dedicated project nature for
> databases.
>
> I am currently developping the New Project wizard and on one of the wizard
> page I would like to display the SQL Model from the selected connection
> profile (I reused the ProfileSelectionComposite for selecting the
> connection) in a ContainerCheckedTreeViewer so that the user could select
> the database objects to export as DDL statement.
>
> Of course to fill the ContainerCheckedTreeViewer I need a ContentProvider
> and a LabelProvider and I have been trying to reuse the existing
> SQLModelContentProviderExtension and SQLModelLabelProviderExtension. But I
> have not met much success so far. I get the first level built and then
> thrown an exception.
>
> It looks like the existing classes are too tied to a CommonViewer class to
> be reused in a ContainerCheckedTreeViewer, but I might be mistaken and
> simply overlooking something.
> Anybody know if reusing any of the existing Content and Label provider
> could be reused in such a fashion ?
> Should I develop my own Content and Label provider to fill a
> ContainerCheckedTreeViewer (and then worry about having to support varying
> ContentExtensions...) ?
>
> Any pointer would be much appreciated...
>
> BTW the source code is hosted at sourceforge.net under the dtp-dbproject.
>
>
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #592360 is a reply to message #48015] |
Sat, 02 August 2008 02:31 |
| Eclipse User |
|
|
|
Originally posted by: philippe.girard.gmail.com
Brian Fitzpatrick wrote:
> Hi Philippe...
> That sounds great! We're always on the lookout for more help. :)
> Do you have a use case for this type of functionality? (I can see some uses,
> but I'm curious what you see as the main goal of going this route.)
I didn't write a formal use case for it, but I could provide one if you'd
like. But as far as how the feature would be used I was thinking along the
following lines:
For a new project the user would select a connection profile and the
database objects to export. The databases object DDL statement would then
be generated to individual files and stored in the project hierarchy which
would be similar the SQL Model hierarchy (Tables, views and routines
folders split repeated for each schemas).
Once created the project could then be put in a version control system
(supplied by eclipse). This is actually one of my main goal: to provide a
easy way of exporting the database objects and then be able to put it
under version control.
The project structures would also be used to stored deployment scripts,
SQL Test case, data generation plan, etc... Any scripts that would be
related to a project.
It would also be possible to import new object to an existing project.
I also want to add a deploy functionality. This would then deploy the
project to a given connection profile.
In a development scenario, the developer would check out the project, make
his modification, deploy it to test.
Of course while the deploy functionality is probably good enough for
dev/testing it is ill suited for production deployment (especially for
tables modification). This is why the next feature I want to develop will
be a schema compare... But one feature at a time ;-)
Also if you see anything else that could be added to the dbproject tool
then let me know. I am mostly developing a tool that I would use, but I am
very much interested in what other people other people would like in a
project functionality.
> All of the existing content and label providers that are hosted in the DSE
> are pretty focused on the Common Navigator Framework. The reason for that
> was that it was easy to provide additional extensions via separate plug-ins
> to contribute various levels of the SQL model hierarchy, etc.
> That said, you should be able to do this by massaging some of the existing
> code. If you use the ProfileSelectionDialogPage and build your own
> ProfileSelectionComposite, you can change the styles that are passed to the
> CommonViewer when it's created.
> The doCreateControl() method (protected void doCreateControl(Composite
> content, boolean flag, boolean multiSelect)) can be changed to provide your
> own checkbox styles (SWT.CHECK) and you should be able to add a selection
> listener to the tree for SWT.CHECK events...
> if(event.detail == SWT.CHECK)
> If that doesn't work, give me a holler and I'll try and come up with an
> example. Hope that helps!--Fitz
Thanks for the tips. I hadn't realized that I could supply the check style
to the common viewer. I am thinking that I could probably extend the
common viewer and add it the ContainerCheckedTreeViewer code for handling
the checkboxes.
This brings me to wonder if it is be possible to limit the Common
Navigator to display only the Schemas section ? Since in this case that is
the only thing I would need to display to the user.
|
|
| |
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #592387 is a reply to message #48045] |
Mon, 04 August 2008 13:49 |
Brian Fitzpatrick
Messages: 500
Registered: July 2009 |
Senior Member |
|
|
And integrating with the version control system is a very interesting idea.
I think a number of developers might be interested in that, as it would be a
way to share database tests, scripts, and whatever else they wanted to
associate with a given connection profile.
My only concern would be that it may be too focused on databases (though
that's what your use case requires). If we were going to do something
similar in DTP, we woul most likely abstract it to handle any kind of
connection profile type and then specialize that for database connection
profiles. ODA is a type of profile that isn't necessarily database-related,
so it would benefit from having the more abstracted way of looking at
things.
Any thoughts on that?
--Fitz
"Philippe Girard" <philippe.girard@gmail.com> wrote in message
news:1ea032669e1c85196159cb7294e6ba16$1@www.eclipse.org...
> Brian Fitzpatrick wrote:
>
>> Hi Philippe...
>
>> That sounds great! We're always on the lookout for more help. :)
>
>> Do you have a use case for this type of functionality? (I can see some
>> uses, but I'm curious what you see as the main goal of going this route.)
>
> I didn't write a formal use case for it, but I could provide one if you'd
> like. But as far as how the feature would be used I was thinking along the
> following lines:
>
> For a new project the user would select a connection profile and the
> database objects to export. The databases object DDL statement would then
> be generated to individual files and stored in the project hierarchy which
> would be similar the SQL Model hierarchy (Tables, views and routines
> folders split repeated for each schemas).
> Once created the project could then be put in a version control system
> (supplied by eclipse). This is actually one of my main goal: to provide a
> easy way of exporting the database objects and then be able to put it
> under version control.
>
> The project structures would also be used to stored deployment scripts,
> SQL Test case, data generation plan, etc... Any scripts that would be
> related to a project.
>
> It would also be possible to import new object to an existing project.
> I also want to add a deploy functionality. This would then deploy the
> project to a given connection profile.
>
> In a development scenario, the developer would check out the project, make
> his modification, deploy it to test.
>
> Of course while the deploy functionality is probably good enough for
> dev/testing it is ill suited for production deployment (especially for
> tables modification). This is why the next feature I want to develop will
> be a schema compare... But one feature at a time ;-)
>
> Also if you see anything else that could be added to the dbproject tool
> then let me know. I am mostly developing a tool that I would use, but I am
> very much interested in what other people other people would like in a
> project functionality.
>
>> All of the existing content and label providers that are hosted in the
>> DSE are pretty focused on the Common Navigator Framework. The reason for
>> that was that it was easy to provide additional extensions via separate
>> plug-ins to contribute various levels of the SQL model hierarchy, etc.
>
>> That said, you should be able to do this by massaging some of the
>> existing code. If you use the ProfileSelectionDialogPage and build your
>> own ProfileSelectionComposite, you can change the styles that are passed
>> to the CommonViewer when it's created.
>
>> The doCreateControl() method (protected void doCreateControl(Composite
>> content, boolean flag, boolean multiSelect)) can be changed to provide
>> your own checkbox styles (SWT.CHECK) and you should be able to add a
>> selection listener to the tree for SWT.CHECK events...
>> if(event.detail == SWT.CHECK)
>> If that doesn't work, give me a holler and I'll try and come up with an
>> example. Hope that helps!--Fitz
>
> Thanks for the tips. I hadn't realized that I could supply the check style
> to the common viewer. I am thinking that I could probably extend the
> common viewer and add it the ContainerCheckedTreeViewer code for handling
> the checkboxes.
>
> This brings me to wonder if it is be possible to limit the Common
> Navigator to display only the Schemas section ? Since in this case that is
> the only thing I would need to display to the user.
>
>
>
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #592448 is a reply to message #48105] |
Wed, 06 August 2008 01:12 |
| Eclipse User |
|
|
|
Originally posted by: philippe.girard.gmail.com
> My only concern would be that it may be too focused on databases (though
> that's what your use case requires). If we were going to do something
> similar in DTP, we woul most likely abstract it to handle any kind of
> connection profile type and then specialize that for database connection
> profiles. ODA is a type of profile that isn't necessarily database-related,
> so it would benefit from having the more abstracted way of looking at
> things.
I agree with you that abstracting it for any kind of connection profile is
best. Although I don't know much about ODA, I will research it.
|
|
|
| Re: Reusing the server explorer in a ContainerCheckedTreeViewer [message #592688 is a reply to message #48075] |
Thu, 14 August 2008 03:12 |
| Eclipse User |
|
|
|
Originally posted by: philippe.girard.gmail.com
Brian Fitzpatrick wrote:
> You bet. You can add a new ViewerFilter to the CommonViewer that filters out
> whatever you want, just like a normal viewer.
> "Philippe Girard" <philippe.girard@gmail.com> wrote in message
> news:1ea032669e1c85196159cb7294e6ba16$1@www.eclipse.org...
>> This brings me to wonder if it is be possible to limit the Common
>> Navigator to display only the Schemas section ? Since in this case that is
>> the only thing I would need to display to the user.
>>
>>
>>
Following up on this. I used the Common Navigator and realized that the
tree is not built until the user expands the nodes to get to the sql
objects. So to be able to use it I would need to build the whole tree
before presenting it to the user. I checked and while there is a collapse
all action. I could not find an expand all action.
I was wondering if such a functionality (building the whole sql model tree
in the common navigator viewer) exists that I missed or if I would have to
code such a functionality.
Again, any pointer than you might have is much appreciated.
|
|
| |
Goto Forum:
Current Time: Sun Dec 22 06:20:31 GMT 2024
Powered by FUDForum. Page generated in 0.05509 seconds |
] 
Search
Help
Register
Login
Home
