nah..i've made many programs in VB6.
Obviously not as many as I have if you think VB6 to .NET is less then the Office 2003 2007 change.
really- you cannot compare them. Office is a user-targeted... Office program suite. Visual Studio is aimed at developers.
It's harder to learn a programming language, and it's even harder to become proficient enough at it to have tidbits of code like this:
Public Function ShowShellContextMenu(hwndOwner As Long, _
isfParent As olelib.IShellFolder, _
cPidls As Long, _
pidlRel As Long, _
pt As PointAPI) As Boolean
Dim IID_IContextMenu As olelib.UUID
Dim IID_IContextMenu2 As olelib.UUID
Dim icm As IContextMenu
Dim hr As Long ' HRESULT
Dim hMenu As Long
Dim idCmd As Long, temppunk As olelib.IUnknown
Dim cmi As CMINVOKECOMMANDINFO
Dim icmPtr As Long
' Fill the IContextMenu interface ID, {000214E4-000-000-C000-000000046}
'old code used IShellFolder library, but didn't work properly.
'Edanmo's lib doesn't include a few things, and uses long pointers instead of objects.
'but we can work around that.
Call DEFINE_OLEGUID(IID_IContextMenu, &H214E4, 0, 0)
' Get a refernce to the item's IContextMenu interface
icmPtr = isfParent.GetUIObjectOf(hwndOwner, cPidls, pidlRel, IID_IContextMenu, 0)
'copy icmPtr into the object for use.
CopyMemory icm, icmPtr, 4
'gawd I can't believe I'm actually successful with a lot of this.
If SUCCEEDED(hr) Then
' Fill the IContextMenu2 interface ID, {000214F4-000-000-C000-000000046}
' and get the folder's IContextMenu2. Is needed so the "Send To" and "Open
' With" submenus get filled from the HandleMenuMsg call in FrmWndProc.
Call DEFINE_OLEGUID(IID_IContextMenu2, &H214F4, 0, 0)
'can't use query interface on icm- use temporary Iunknown.
Set temppunk = icm
Dim Ictxmenu2ptr As Long
Call temppunk.QueryInterface(IID_IContextMenu2, Ictxmenu2ptr)
If Ictxmenu2ptr <> 0 Then
CopyMemory ICtxMenu2, Ictxmenu2ptr, 4
End If
' Create a new popup menu...
hMenu = CreatePopupMenu()
If hMenu Then
' Add the item's shell commands to the popup menu.
If (ICtxMenu2 Is Nothing) = False Then
Call ICtxMenu2.QueryContextMenu(hMenu, 0, 1, &H7FFF, CMF_EXPLORE)
Else
'if no IContextMenu2 (probably Win95, or NT4.)
Call icm.QueryContextMenu(hMenu, 0, 1, &H7FFF, CMF_EXPLORE)
End If
If SUCCEEDED(hr) Then
Dim MenuClasser As CContextSubClasser
' Show the item's context menu-
'BUT FIRST-
'create the CContextSubClasser class, and initialize it. It should handle events so that such things as the Send To Menu are populated correctly.
If Not ICtxMenu2 Is Nothing Then
Set MenuClasser = New CContextSubClasser
Debug.Print "Initializing MenuClasser...."
MenuClasser.Init hwndOwner, ICtxMenu2
End If
idCmd = TrackPopupMenu(hMenu, _
TPM_LEFTBUTTON Or TPM_RIGHTBUTTON Or _
TPM_LEFTALIGN Or TPM_TOPALIGN Or _
TPM_HORIZONTAL Or TPM_RETURNCMD, _
pt.x, pt.y, 0, hwndOwner, 0)
Set MenuClasser = Nothing
' If a menu command is selected...
If idCmd Then
' Fill the struct with the selected command's information.
With cmi
.cbSize = Len(cmi)
.hwnd = hwndOwner
.lpVerb = idCmd - 1 ' MAKEINTRESOURCE(idCmd-1);
.nShow = SW_SHOWNORMAL
End With
' Invoke the shell's context menu command. The call itself does
' not err if the pidlRel item is invalid, but depending on the selected
' command, Explorer *may* raise an err. We don't need the return
' val, which should always be NOERROR anyway...
If (ICtxMenu2 Is Nothing) = False Then
Call ICtxMenu2.InvokeCommand(cmi)
Else
Call icm.InvokeCommand(cmi)
End If
End If ' idCmd
End If ' hr >= NOERROR (QueryContextMenu)
Call DestroyMenu(hMenu)
End If ' hMenu
End If ' hr >= NOERROR (GetUIObjectOf)
' Release the folder's IContextMenu2 from the global variable.
Set ICtxMenu2 = Nothing
' Returns True if a menu command was selected
' (letting us know to explicitly select the right clicked object, if needed)
ShowShellContextMenu = CBool(idCmd)
End Function
Alright... So it's not a "tidbit"...
I put forth the challenge of showing the right-click explorer menu for a file using .NET. Not sure if the framework provides it...
Anyway, what I'm trying to say is although it's not always easy to learn a Word processor- it's easy to learn the basics. However, with programming, the basics don't often cover what you want to do. With VB6, I hit my head against this wall quickly. Thus my now constant use of direct calls to the API to work around it's limitations.
Most people who use office, on the other hand, don't hit this brick wall. They use a few basic functions of the word processor, and it's quite sufficient.
Basically, the Ribbon was a way to "beginner-friendlyize" the swath of commands that were in the menus and commandbars of previous versions. As an example, how often do most users open the VBA editor, or perform Mail Merge or create pivot tables?
my guess is not often. However having these options in the menus distracts beginners from whatever it is they are looking for.
Although I must admit that it is a pain for office veterans; but it's not as bad as VB2 through 6 veterans...
