At the beginning, I really hate access 2007 because of Ribbon. It is so complicated for me to create menubar and toolbars. But I suppose I have no choice at the moment coz I need so of its features. And so I studied how to make it manually.
Last night as I studied it, it follows some syntax and parts of ribbon. I learn some of them last night. And so I decided to make my own access ribbon creator with access itself. But as I said, I learned only few of its syntax and parts.
Can anybody share their knowledge of the ribbons syntax and ribbon parts. I have manage to search in the internet but I dont know if they are complete. I got some from access-freak.
Somehow last night after studying the ribbon process, I can say generally "WOW I like it !"
I have seen ribbon customizers in the internet but they are paid softwares.
Somehow, I also dont get it, why Microsoft did not create an add-in for ribbon customizer since this is their product. Why should a third-party must create it and another paid software. So many outlay of cash now...hahaha. Just a thought.
Somehow, I also dont get it, why Microsoft did not create an add-in for ribbon customizer since this is their product. Why should a third-party must create it and another paid software. So many outlay of cash now...hahaha. Just a thought.
I realize that I'm not answering your question - just raising a new one.
I think that most of us were taken by surprise with the inability to easily modify menus as we were for the past 10 years and Microsoft does not seem to consider this a priority for Access 2010 (Clint Covington posted on a blog that this is not a problem because there exist 3rd party tools to address it! I can't think of any other "upgrade" to a product that removes basic functionality that isn't considered a problem because you can pay 3rd parties to rectify it).
My question is: with all the touting of Access 2010, what other basic functionality will they be removing but not telling us about? They will try to showcase all the fancy new gizmos in the new software but if they think it's a good idea to remove what we require so someone else can develop a solution for us to buy, I will definitely not be running out to buy Access 2010.
I apologize in advance if this is too far off topic.
Would this include the ability to edit a toolbar/menu bar that I created in a previous version of Access (e.g. XP or 2003)? Can I drag and drop commands like I've always been able to?
Would this include the ability to edit a toolbar/menu bar that I created in a previous version of Access (e.g. XP or 2003)? Can I drag and drop commands like I've always been able to?
I can see where you are going with this, but again toolbars/menus from previous versions are still considered "old and out of date" and available from the Add-Ins tab. So, no you cannot drag and drop commands like you've been able to do and I know you don't like that. I'm not thrilled with that either but things do change and this change is here to stay and so you can complain about it, but I do not see it doing any good.
So, you can either embrace the new methods, or fight against it and remain on the older versions. You don't have to upgrade - yet. You could remain on the older versions for years to come. There are still a lot of people using Access 97 out there (although they probably have some severe security holes due to it as there are no updates being created for them). Me, I want to go to 2010 for the new data macros and several of the other new features.
I can see where you are going with this, but again toolbars/menus from previous versions are still considered "old and out of date" and available from the Add-Ins tab.
I see what you're saying. The problem is that possibly in the millions of databases were written using the Access 2000-2003 format and it's a shame to have to scrap the menus and completely rewrite them for more recent versions of Access. This is probably a problem to 3/4 of the people who post on this message board.
I think that hundreds of thousands of people found the same frustration when they wrote elaborate programs using VB versions 3-6, for example, and then found out that their highly complex work that took years and years to develop is now useless because Microsoft switched their VB to .NET. (No, the "converter" that's supplied doesn't really work )
So, no you cannot drag and drop commands like you've been able to do and I know you don't like that. I'm not thrilled with that either but things do change and this change is here to stay and so you can complain about it, but I do not see it doing any good.
I've said this before but I think this leaves many people scratching their heads trying to figure out why necessitating coding for something that previous versions allowed a drag and drop interface is considered an "upgrade". Does that mean that the next version of Windows will be DOS, just much slower? (that was sarcasm...not intended seriously for those people who didn't catch that)
There are still a lot of people using Access 97 out there (although they probably have some severe security holes due to it as there are no updates being created for them).
This is true, but people who switched from Access 97 to 2000, XP or 2003 didn't LOSE functionality that they used to have, and certainly didn't have to scrap huge sections of their applications to rewrite them using code. (Ok, I will confess that there were some funky thinks in Access 2000 that took years to patch and we all know about the flickering tabs in Access 2003 and the problems caused by the first few patches until the final patch that came out years later, but that's a different topic)
I read the MS developer blog on Access 2010. There certainly does seem to be some attractive new features but as I said, I'm worried about what they will REMOVE when I get the new version. I was pretty surprised when I got Access 2007 and only then found out that I couldn't export Reports to Excel.
But, I know what you're saying and it would be nice if past functionality could be kept forever. Don't know that I would like to be a developer who had to always keep my previous versions working in future versions of my product. It could be a real pain to do so. So, think of it that way too. What if you had to maintain functionality of stuff forever. It could be a bit overwhelming and impossible to maintain. So, sometimes there has to be a "break."
And, I know you are saying that the removal of these things affect hundreds of thousands of users. Well, I would have to say that, perhaps there are. But maybe there aren't. Do you have a good source for your numbers? Can you prove it? Therein lies the problem because Microsoft has their own studies which show that it wasn't being used as much as you claim (not saying they are right, mind you) and therefore they acted upon what they have for their studies. Several of the changes got big boos from the MVP community. The ribbon was one of them.
Ah...there's the problem. That means I went a year and change without something I was able to do before I switched to Access 2007. And as I say, what will I not be able to do when I buy Access 2010 if and until there's a second service pack sometime in 2012...?
...Don't know that I would like to be a developer who had to always keep my previous versions working in future versions of my product. It could be a real pain to do so. So, think of it that way too.
I would say that this would depend on whether it's a step "up" or a step "down". And I would regard having to code something I used to be able to drag and drop a step "down".
It's completely based on a guess and intuition...I won't pretend otherwise.
The closest thing I would base a guess on (I know this is remote) is that I learned to program VB from a book by Peter Norton. He did cite in the forward of the book some statistic as to how many developers were estimated as using VB and the number was STAGGERING.
From there I applied complete conjecture that people who have written applications that have to be started from scratch would likely ruin someone's afternoon - even if it's 25% of those programmers, we're talking a very substantial number.
Therein lies the problem because Microsoft has their own studies which show that it wasn't being used as much as you claim (not saying they are right, mind you) and therefore they acted upon what they have for their studies. Several of the changes got big boos from the MVP community. The ribbon was one of them.
That's interesting. Do they make those studies available so I can see your source?
SHADOW
PS. When I posted my response, I realized that you were asking about the Access developers, not the VB developers. My guess of hundreds of thousands was with regard to VB, not Access. I don't even claim to guess numbers with regard to Access.
Nope, they don't. We just get told info as part of the product group interaction with MVP's. So, I can't really support or refute either their statement or your statement. But it is clear that neither comes together.
So, anyway - life is what it is and MS is what it is and we either use their stuff or not. If we do, we play by their rules. If we don't like it, we find something else to use; for right or wrong.
I bought a book "RibbonX" and learned ribbon in just a few days. It seemed quite easy to understand the xml and as long as you keep it organized, easy to track.
I needed a dynamic menu to change everytime my subform source changed as I couldn't have my ribbon per form due to the fact my whole app is a one form app with changing subforms.
The vba was simple enough. I created my groups in the ribbon and they all called a getvisible function to determine when the menu was visible.
In just a few days from scratch, I had a menu that was completely dynamic, had editboxes, combo boxes that updated to add the record in a list when a record was added, multi tree split buttons and updated text etc etc
as long as you remember to invalidate the ribbon to force to update change.
I posted an example recently in
modules of a timed toggle button.
I have a plan to build a ribbon tool. I've created various parts for myself but never managed to get the time to put it all together. I will soon, once my long time app is finally completed!
Wow, yes I can see you have your opinion all over this post Shadow9449 but that is ok because previously when I am very rebellious towards ribbon I have also done so many post of not wanting it. I agree with you that it was much more easier back then using drag and drop in create menus and toolbars but after awhile, it came to my mind what Bob exactly stated here in post number 9.
To Bob Larson:
I have tried using clayton ribbon customizer and it was not that extensive.
Thought I admit that this is microsoft product and we have choice if we use it or not, but I think it is also true that microsoft is creating product for profit. So it follow, without its customers, there will be no profit. Therefore, it is also be considered what its customers wants and needs to reach its profit goals. Though I cannot do something for 2007, however for 2010 version, I have suggested in their 2010 blog, if ribbon is to stayin the current and future version, then microsoft should provide its customers add-in tool to create the ribbon and not burden the customers to buy 3rd party tools which is suppose to be their product and if it is possible, let the customer of the product to have an option in the access option to either use the ribbon or the classic menu. Thereby a win-win solution.
To NigelShaw:
I have also tried those two tools you mentioned here from avus gunter www.accessribbon.de and pschmidt.
------------------------------------------
Actually I have probably googled everything and tested it myself. However, I can see that they are not that extensive and so as I have been studying it, I realized that the ribbon has its parts and syntax to follow. That is why I ask from our forum maybe someone may extend their knowledge regarding:
1. WHAT ARE THE PARTS OF THE RIBBON?
2. WHAT ARE THE COMPLETE SET OF XML SYNTAX
However, I can see that the two above were not yet given answers but rather third party tools and opinions only.
I am planning to make my own ribbon customizer using access but I need the two above because I still lack parts of those two.
hunters site has lots of good demos showing ribbon examples however, I will later today put a good description down of what's included in the xml construction.
One thing you need to consider when building your tool is to check that the xml command hasn't already been placed in the line as this will error. For example-
everything with the ribbon should be included in these so at the very bottom, place
Code:
</ribbon>
</customUI>
every group
Code:
<group>
should be balanced with
Code:
</group>
every tab
Code:
<tab>
should be balanced with
Code:
</tab>
every menu
Code:
<menu>
should be balanced with
Code:
</menu>
every splitbutton
Code:
<splitButton>
should be balanced with
Code:
</splitButton>
notice the capitalization.
splitButton is NOT the same as splitbutton or Splitbutton or SplitButton
VBA callbacks
set up your OnRibbonLoad
'this goes in your public module or at the top of your module
Code:
Public gobjRibbon As IRibbonUI
'any ribbon groups you want to control the visibilty of needs to be made public
'this is then controlled via the GetVisible sub
Code:
Public bolGrpOne As Boolean
Public bolGrpTwo As Boolean
Public bolGrpThree As Boolean
Public bolGrpFour As Boolean
Code:
Public Sub OnRibbonLoad(ribbon As IRibbonUI)
'Callbackname im XML File "onLoad"
Call PopulateSelect
Set gobjRibbon = ribbon
'set the public boolean to your desired visibility options for loading the ribbon
'this will be called by the GetVisible routine
bolGrpOne = True
bolGrpTwo = True
bolGrpThree = True
bolGrpFour = False
End Sub
your xml calls the GetVisible routine
Code:
Public Sub GetVisible(control As IRibbonControl, ByRef visible)
'Callbackname in XML File "getVisible"
Select Case control.ID
Case "GrpOne"
visible = bolGrpOne
Case "GrpTwo"
visible = bolGrpTwo
Case "GrpThree"
visible = bolGrpThree
Case "GrpFour"
visible = bolGrpFour
Case Else
visible = True
End Select
End Sub
if your ribbon is dynamic, it needs to be reset. use this routine to do that
Code:
Public Sub RibbonInvalidate()
gobjRibbon.InvalidateControl "GrpOne"
gobjRibbon.InvalidateControl "GrpTwo"
gobjRibbon.InvalidateControl "GrpThree"
gobjRibbon.InvalidateControl "GrpFour"
End Sub
you can control the visiblity as you move through the ribbons by setting
set up specific menu routines that you want to show the ribbon groups
S
Code:
ub Menu1()
bolGrpOne = True
bolGrpTwo = False
bolGrpThree = True
bolGrpFour = True
Call RibbonInvalidate
End Sub
Sub Menu2()
bolGrpOne = False
bolGrpTwo = False
bolGrpThree = False
bolGrpFour = True
Call RibbonInvalidate
End Sub
Sub Menu3()
bolGrpOne = False
bolGrpTwo = True
bolGrpThree = True
bolGrpFour = True
Call RibbonInvalidate
End Sub
Sub Menu4()
bolGrpOne = False
bolGrpTwo = False
bolGrpThree = False
bolGrpFour = True
Call RibbonInvalidate
End Sub
set up the onGetLabel to fill the label text on the menus
Code:
Sub onGetLabel(control As IRibbonControl, ByRef label)
Select Case control.ID
'option 1 is calling a routine to get data
Case "lblWelcome"
label = GetWelcomeMessage()
'option 2 is hard typed
label = "My Label"
Case "lblToday"
label = "Today is " & FormatDateTime(Date, vbLongDate)
Case "lblRegister"
label = GetRegistered()
End Select
End Sub
Set up the get welcome message to populate a label
Code:
Public Function GetWelcomeMessage() As String
Dim db As DAO.Database
Dim rst As DAO.Recordset
Set db = CurrentDb()
Set rst = db.OpenRecordset("tblMyTable", dbOpenDynaset)
If Not rst.EOF Then
rst.MoveFirst
LongName = Nz(rst!FirstName, "") & " " & Nz(rst!LastName, "")
End If
GetWelcomeMessage = "Welcome " & LongName
rst.Close
db.Close
Set rst = Nothing
End Function
'this function is very similar to the the GetWelcomeMessage and is optional
'i used this to show in the ribbon if the program was registered or not
Code:
Public Function GetRegistered()
Dim db As DAO.Database
Dim rst As DAO.Recordset
Set db = CurrentDb()
Set rst = db.OpenRecordset("tblMyRegisterTable", dbOpenDynaset)
GetRegistered = rst!Registered
If rst!Registered.Value = False Then
GetRegistered = "'30 DAY TRIAL'"
Else
GetRegistered = "Registered to " & rst!YourCompanyName
End If
rst.Close
db.Close
Set rst = Nothing
End Function
'an option if you wanted to show register details in the main ribbon tab description
Code:
Public Function GetTabDesc()
Dim db As DAO.Database
Dim rs As DAO.Recordset
Dim strCompName As String
Set db = CurrentDb
Set rs = db.OpenRecordset("tblMyRegisterTable", dbOpenDynaset)
bolGetTabDesc = rs!Registered
strCompName = rst!YourCompanyName
rs.Close
db.Close
Set rs = Nothing
Set db = Nothing
If bolGetTabDesc = False Then
GetTabDesc = "Trial Version"
Else
GetTabDesc = "Registered to" & strCompName
End If
End Function
'to populate a dynamic listbox whereas a new record will be forced into the ribbon listbox
Code:
Public bolList As Variant
This gathers the data
Code:
Sub PopulateSelect()
Dim db As DAO.Database
Dim rst As DAO.Recordset
Dim lngLoopCount As Long
Set db = CurrentDb()
Set rst = db.OpenRecordset("tblMyTable", dbOpenTable)
On Error Resume Next
lngLoopCount = 0
With rst
If .EOF Then .MoveFirst
glngItemCount = .RecordCount
ReDim bolList(glngItemCount - 1)
Do While Not (.EOF)
bolList(lngLoopCount) = ![CompanyName].Value
.MoveNext
lngLoopCount = lngLoopCount + 1
Loop
End With
rst.Close
db.Close
Set rst = Nothing
Set db = Nothing
Exit Sub
End Sub
This controls the click action
Code:
Sub cboSelect_Click(control As IRibbonControl, text As String)
Dim sCName As String
Dim rs As DAO.Recordset
sCName = "[CompanyName] = '" & text & "'"
Forms![mainform].SetFocus
With Forms![mainform]
Set rs = .RecordsetClone
rs.FindFirst sCName
If Not rs.NoMatch Then
.Bookmark = rs.Bookmark
Else
If MsgBox("The listbox item you have entered is not listed. would you like to add it?", vbYesNo, "messagebox description") = vbYes Then
AddListBoxItem ' or whatever routine you have to add a new record related to the listbox contents
Exit Sub
End If
End If
End With
End Sub
'these are not altered at all but are required to make the above populate the listbox
Code:
Sub cboSelect_getItemCount(control As IRibbonControl, ByRef returnedVal)
returnedVal = glngItemCount
End Sub
Sub cboSelect_getItemID(control As IRibbonControl, index As Integer, ByRef ID)
ID = "itemcboSelect" & index
End Sub
Sub cboSelect_getItemLabel(control As IRibbonControl, index As Integer, ByRef returnedVal)
returnedVal = bolList(index)
End Sub
I have attached a really good tool to select and copy the built in Msos that are available. its easy enough, browse the tabs, select the image you want and the whole xml is copied to the clipboard. you have to keep the .doc in the same location as the db file for it to work.
if someone could make this into a plugin or addon, that would be great.
if you require anything else, please let me know and i'll see if can help further.
)
