there is no ribbon war honest. just independent views thats all. there is nothing wrong with anyones view. some people like, some people dont. thats just the way it is. i certainly wont lose any sleep over it and im pretty sure Dat wont either.
i think it needs pros / cons to understand what people do / do not like about it. heres an idea, we could vote on it
I remember Brent (datAdrenaline) giving his "feedback" (/appropriately subtle complaint) to the whole Access team about the ribbon implementation.
I recall thinking "You go Brent!!!.... I'll just be hiding over here..."
:-D
Nah, FWIW I felt it came across in his previous post that he's not anti-ribbon.
He's just vocal in the areas that it could do with substantial improvements.
I agree wholeheartedly NO WARS! ... just good respectful technical discussion ...
....
>> what is so hard with clicking a tab? <<
Its not hard to click a tab, but its the fact that you have to when for EVERY prior version the user did not have to click something to see what they could do ... the toolbars that were appropriate were shown, thus providing at least a sub-set of what could be done with the active object. And if the user needed to navigate the menu's, the only options were those that were appropriate for the selected object/item.
>> we are not dealing with word, this is mainly focused on Access as this is what the discussion is for <<
Well sortof ... the Ribbon is an office wide thing and the problems have the ability to cascade through out the suite. I will look in the Ribbon tonight or tommorrow to see where there is a "lack of information" similar to that which I used Word's example.
>> me: No where on the Ribbon can we save our objects! ...
you: > many programs are like this. autoCAD, VectorWorks etc. there is nothing wrong with saveas through a menu. however, again this can be easily fixed by adding it to your main home tab. beforeMso i believe it might be without looking up.
< <<
we are not dealing with AutoCAD, Vectorwork etc, this is mainly focused on Access as this is what the discussion is for! .... ROFL!! ...
I never said there was something wrong the SaveAs ... I mean when I am working on a Form in Design View, I may want to save the design with out leaving the Design View, so in prior versions I click on the disk that is RIGHT THERE on the toolbar ... in A2007, I have to click on the office button and chose Save, and yes you CAN add that to the QAT fairly easily. But, for many, adding it to the Home Tab of the Ribbon is ... well ... next to impossible .... Ultimately, to me the Office Button throws your mind in a bend, here we are working with the Ribbons, learning all the stuff ... hearing "Menu's are Not Hip!" ... then <tire screetch noise> ... Oh .. yes ... that option is on the Office MENU! ... What!!! .... I thought menus were not cool anymore! ...
>> Me: selecting on an object in the NavPane, *should*, at a minimum effect the View button on the Home ribbon
> you: i dont quite follow this. sorry < <<
Simply click on an item in the NavPane ... now ... look at the View button of the Home Tab .... I would think that SOMETHING on the Ribbon would indicate what you can do with the object you just selected ... but ... the View button is disabled. It is my suggestion that the View button contains the same items as the right click menu on the object in question, that way NON-familar users KNOW they can do something with the object they have selected ... this is what I mean by saying the NavPane and the Ribbon are dis-connected ... The Ribbon only seems to sorta know about what is opened in the work space, but it has no knowledge of what is going on in the NavPane.
>> i would hazard a guess that the other programs like word / excel are not built for the development like Access is. probably why excel has a recorder for easy non technical use whereas Access is mainly development so why a need for even more development tabs? <<
For consistency and re-inforcement of the fact that Access CAN be a development environment. It is my opinion that A2007 was a huge effort to convince folks that they do not need to be a developer to use Access ... so ... my "conspiracy theory" mind set says that the Access team did NOT put a Developer tab in there because they did not want to scare people off! ... LOL! ... I am sure there are other reasons, but I still don't like the absence of a tab with that label.
>> then maybe the dropdown part of the delete should be exercised. from there, a record, column and object can be deleted. again, all appropriate items in one place. would you rather a "delete object" in one place, "delete field" in another and "delete column" in another? <<
I honestly do not have a problem with a drop down button for the Delete ... but the button is in the "Records" group, that is the problem. Why would a new user be looking in the Records group to delete a Form object? (maybe the command should be on the Office Menu, under the Save command ... I should not be able to manipulate items that are not records while using the Records group commands. And "Yes" I would RATHER have a button for Delete Object (on the Create tab) and Delete Column (on the Table Design Tools tab)
>> Application.LoadCustomUI objYourRibName, strYourXML ( obviously, your other items are declared too ) <<
I think you missed what I was saying ... I believe (its been awhile so my memory may be sketchy) ... using something like the following ...
Code:
In the Ribbon XML
-----------------
<[SIZE=2][COLOR=#800000]customUI[/COLOR][/SIZE][SIZE=2][COLOR=#ff0000]xmlns[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]=[/COLOR][/SIZE][SIZE=2]"[/SIZE][SIZE=2][COLOR=#000000]http://schemas.microsoft.com/office/2006/01/customui[/COLOR][/SIZE][SIZE=2]"[/SIZE]
[SIZE=2][COLOR=#ff0000] onLoad[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]=[/COLOR][/SIZE][SIZE=2]"[/SIZE][SIZE=2][COLOR=#000000]CallbackOnLoad[/COLOR][/SIZE][SIZE=2]"[/SIZE][SIZE=2][COLOR=#0000ff]>[/COLOR][/SIZE]
[SIZE=2][COLOR=#0000ff]</[/COLOR][/SIZE][SIZE=2][COLOR=#800000]customUI[/COLOR][/SIZE][SIZE=2][COLOR=#0000ff]>[/COLOR][/SIZE]
[COLOR=#000000]In VBA[/COLOR]
[COLOR=#000000]-------[/COLOR]
[FONT=Courier][COLOR=#0000ff]Option Compare Database[/COLOR][/FONT]
[FONT=Courier][COLOR=#0000ff]Option Explicit[/COLOR][/FONT]
[COLOR=#000000][FONT=Courier][COLOR=#0000ff]Public[/COLOR] gobjRibbon [COLOR=#0000ff]As[/COLOR] IRibbonUI[/FONT][/COLOR]
[FONT=Courier][COLOR=#000000][COLOR=#0000ff]Sub[/COLOR] CallbackOnLoad(ribbon As IRibbonUI)[/COLOR][/FONT][COLOR=#000000]
[FONT=Courier] [COLOR=#0000ff]Set[/COLOR] gobjRibbon = ribbon[/FONT]
[/COLOR][FONT=Courier][COLOR=#0000ff]End Sub[/COLOR][/FONT]
Once you loose gobjRibbon (ie: an error or ???) ... you can not get it back until you restart your application. Please try it out, and let me know if you are successful, and how you did it if you are! That is why I would like another "hook" from VBA to the Ribbon object with something like:
Set gobjRibbon = Applcation.RibbonX
with the property RibbonX returning an IRibbonUI object.
>> im not a fan of the tabs in a db. i have 1 ribbon tab only and this states the validation of the db licence. other than this, my RibbonLoad sets the required items visible to true and all others to false. as diferent forms are visited, the relevant objects are made visible to meet the requirements <<
So .. you have just made the Ribbon act like the old Toolbars behave! ... show (up front) what the user can do in the applications current state. This is exactly my point with the suggestion that the GROUPS or CONTROLS become more dynamic, specifically in the Home Tab since it likes to retain the focus. As an example of this need, open up a brand new BLANK database ... How many controls on the Home Tab are enabled? ... I would think that it would be MUCH more intuitive for a new user to have a Group named "Database Objects" appear on the Home Tab. The group could contain a "Create" drop down button that drops down all the objects that you might be creating ... (Table, Form, Report, etc ... ) the action of the drop down could launch something to guide the user towards creating the selected object. An other button could be a "Delete" button that would delete a selected object in the NavPane ...
After thinking about this, I would actually lump the two suggested buttons with the "View" drop down button on the Home Tab and leave them there at all times, this, of course assuming the View button become aware of the NavPane ... as the user becomes more advance, the additional "create" type capabilities could be explored in the "Create" tab.
BTW ... Leigh was spot on with my view point of the Ribbon... I am not ANTI-Ribbon (... resistance if futile ... we are the Borg ...) ... but the Ribbon is replacing a very mature methodology of thinking that works very well (quick FYI .. did you know that the Ribbon is actually contain in a Toolbar object? ... so is the NavPane, as well as the Property Sheet!). The initial implementation of the Ribbon does not equal its predessesor in MANY facets of what a User Interface should provide, but I hope that as MS listens, they can improve the Ribbon to be equally as viable and intelligent as the prior Toolbar/Menubar UI.
Simply click on an item in the NavPane ... now ... look at the View button of the Home Tab .... I would think that SOMETHING on the Ribbon would indicate what you can do with the object you just selected ... but ... the View button is disabled. It is my suggestion that the View button contains the same items as the right click menu on the object in question, that way NON-familar users KNOW they can do something with the object they have selected ... this is what I mean by saying the NavPane and the Ribbon are dis-connected ... The Ribbon only seems to sorta know about what is opened in the work space, but it has no knowledge of what is going on in the NavPane.
i tried your suggestion but do not get a disabled view button. i selected-
table
form
query
macro
module
each selection had design options with the view button on the home tab.
i do think the the tabs can be confusing so definately need looking at. the only reason i chose to supress tab usage was because i needed to remove any circumstance where a user might make a wrong turn.
i respect your comments and would not disagree with you, its your opinion as mine.
in respect of the need to restart a db if you get errors, this is slightly misled. i dont need to restart when i get an error and i do get a few
i will get together a sample db with a ribbon that will try and match your descriptions using the standard built in actions along with a process that doesnt need a restart but ive got to finish my program first.....
i will then be finishing a ribbon builder that can be added to access as an addin. unfortunately, it might be limited to access only though but hey, you cant have everything.
>> i tried your suggestion but do not get a disabled view button. i selected-
table
form
query
macro
module
each selection had design options with the view button on the home tab.
i do think the the tabs can be confusing so definately need looking at <<
I am not confused ... well thats debatable! ... ... however, it seems that you may be opening the object ... take a look as the screen shots I have attached as a word document ... you will see, the with NO objects open, the View button is disabled... it is my contention that is should have some commands related to the object that is selected in the NavPane ...
>> i respect your comments <<
And I respect yours! ... I want to re-interate that my comments are not made out of an "anti-ribbon" motive. I think it is important to discuss how the ribbon could/*should* be better... To me there is just an overiding sense that the Ribbons were implemented just a little to prematurely.
>> in respect of the need to restart a db if you get errors, this is slightly misled. i dont need to restart when i get an error and i do get a few <<
You only have to restart if you need the object reference to the IRibbonUI, which, I beleive, you need if you want to invalidate individual controls (which is analogous to "Refresh" or "Requery").
>> ... but ive got to finish my program first..... <<
Whoa!!! ... I that was my "time frame", I'd NEVER get anything done!!! ...LOL! ...
Honestly, I will be REALLY looking forward to your Ribbon samples! If/When you post them or have them ready, It would be great to get a PM!
I typically use Access as the frontend to backend SQL/MySQL databases. One area I would like to see improved on is the ability to quickly switch a set of linked tables from Prod to DR to UAT to Dev etc. At the moment it a cumbersome process which requires a DBA to manually change each linked table.
Only getting to know 2007 now so apologies if something has already been done in this version to address this.
I typically use Access as the frontend to backend SQL/MySQL databases. One area I would like to see improved on is the ability to quickly switch a set of linked tables from Prod to DR to UAT to Dev etc. At the moment it a cumbersome process which requires a DBA to manually change each linked table.
Only getting to know 2007 now so apologies if something has already been done in this version to address this.
If you use "Linked table manager" you can switch all your table in one go if they are in the same database. This was definitely available in A2003 so I assume it is in A2007 as well
Well, I went, I saw, and I shared our opinions. I got through the most voted for items on the list (other people were there too, and they had their own opinions!).
Thanks everyone who contributed to this discussion, hopefully our feedback will have some effect on the direction of access, you know, like a butterfly flapping a wing on the other side of the world
Yep -
On the network/linking issues, they were very unsympathetic, just repeated workarounds for checking tables, etc.
They were somewhat receptive to the idea of having some sort of interface for an editable non-aggregate crosstab.
They agreed completely with the need for using different registry keys for different versions and/or having some sort of version independent run time that could be installed anywhere without breaking whatever other version of office was installed on the machine.
They thought I was in dreamland to ask to be able to go from mdb to exe
They agreed on the need for more and better native controls (less reliance on activex). One comment was that the native access controls are essentially dead graphics, while the active x controls are actual "windows", which is why you can do drag drop with the active x controls, but not with the native controls.
They were flumoxed when I asked for continuous form on a continuous form, but seemed somewhat receptive to the idea once I described an example from one of my projects.
They agreed with the QBE suggestions about being able to retain formatting, comments, etc in SQL view, and being able to drill down to subquery as well.
There was quite a bit of discussion about the ribbon/xml stuff. The best quote of the night was," I though I was done with ribbons when I went to a word processor." The consensus was that ribbon development was cut short by the deadline, that it will be better in future versions, until then, use a third party development tool to build the ribbons.
On triggers, application events, etc., the answer was that this is JET, not an actual server, so most of that is basically not possible. They recommended just going to a SQL Server backend to get those features.
As far as going "back" to the 2003 feel of things, several issues were brought up, such as being able to have the WHOLE database window back again, bringing back ULS, export functionality that was removed, etc. Doesn't seem to be a lot of hope on these.
On the inclusion of Access with Office vs. Visual Studio, apparently there is a group of people within MS advocating for this. Who knows what will happen.
Didn't get a chance to bring up naming conventions.
They reiterated that 2007 was for the users, and the next version will make us happy. We will see . . .
That's all I can recall right now, maybe more of my memory will return later on in the morning.
Thanks for sharing; hopefully something come out of it.
I have to admit, though, I was surprised to hear that they were unsympathetic WRT networking issues... What else would we use to link to other backends, even an Access backend? Two cups and a string? Ah, well.
I find this difficult to believe, though I haven't done enough work in Access 2007 to validate.
In Word 2007, it takes 7 mouse actions to set the size of your document to Text Width. In older versions, it takes 3 or 4. Try quick printing anything in any 2007 Office product. It takes a lot more work than in older versions. Also, saving as (or just saving).
I've been on survival for a few days so i missed the start, after having read all the pages, i have a few suggestions:
- I like the Silverlight approach to property editting. Just type the name of the property in the box or a few characters and there you are.
- I also like the Access window to be removed and only show the form i programmed/designed *like* an executable. So it doesn't look like access but it is. Perhaps including this option in the MDE is a possibility.
- What is need is Control Array's. They give me the possibility to create controls dynamically. Like in VB6. On both forms and reports.
- I like to see a Treeview wizard.
- A object level approach to Visual Source Safe. (VSS) So when i store my changed object in VSS, only the changed object is stored and not the complete Access MDB file.
Although I am not a programmer/developer IT type, I can think of two items I'd like to see.
One - the ability to undo deletes of objects like Forms etc. We can undo delete in almost every other aspect, why not with objects?
Two - the ability to group objects together. For example a query called Transactions can be grouped with a form called Transactions and any associated report/macro. As it is use a naming convention to collect related objects (queries, forms etc) in a logical swquence. Why not be able to group items into the equivalent of subfolders etc?
They were somewhat receptive to the idea of having some sort of interface for an editable non-aggregate crosstab.
...
They were flumoxed when I asked for continuous form on a continuous form, but seemed somewhat receptive to the idea once I described an example from one of my projects.
I'm sorry I missed the chance to have input but these two items strike me as being the most interesting new tools that might happen. I have wanted both on more than one occasion. It's encouraging to hear that they were open to the idea. These would actually make me want to upgrade from A2K/A2003!
And the ability to have a gui that allows subdirectories to better organize the existing types of db objects, and creating entirely user-defined object groupings would be fantastic.
Not sure if it was already mentioned, but I'd like to see expressions that have the concept of implicit reference, just to make my life easier (see post earlier today ).
I am Ac 2003 - user
1.
TOOL-Beautify code: Like in Visual FoxPro
2.
Full Help for Undocumented command switch /Decompile
( In Help Ac 2003 Nothing )
3.
Tool Import Wizard
New Button **Import ALL Objects** from old database,
in One Click (all-Tables, all-forms,...)
4.
Backup Tool with auto-increment-encreasing
My_db_00001.mdb (My_db_00001.zip,My_db_00001.rar)
My_db_00002.mdb ,...
5.
After first Crash, crash wizard save your DB backup to xPAC_DFT_Backup.MDB...
After SECOND Crash, crash wizard save your DB backup to My_password.MDB...
6.
VBE tool Find/Replace: i can NOT replace 'Find-text'
with 'Find-text' + vbNewline
7.
VBE Module view (Declaration)
#Const gflgCompileATR = False
#Const gflgCompileALL = False
Is missing filter/Header for conditional constants, for example:
#If Not gflgCompileATR Or gflgCompileALL Then, My_function1
<----------#Const header------------------>, functions/subs
8.
Crash Support in Ac-Help, what should i do after crash...
Ah, well.
