UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V  1 2 >  (Go to first unread post)
   Reply to this topicStart new topic
> Treeview in 64 bit, Office 2010    
 
   
KantWin
post Jun 1 2010, 05:57 PM
Post#1



Posts: 581
Joined: 1-August 02
From: Alabama


Howdy!
did a search on the forums, but didn't find an answer.
Omay be late to the party, but this is a concern of mine.
I understand that the 64 bit Access 2010 will do away with the common controls library that includes items such as the treeview.
What are the options to replace that?
Go to the top of the page
 
GinaWhipp
post Jun 1 2010, 09:55 PM
Post#2


UtterAccess VIP
Posts: 534
Joined: 11-October 06
From: Ohio, USA


The only option that comes to mind is...
http://msdn.microsoft.com/en-us/library/d4fz6xk2(VS.80).aspx
Go to the top of the page
 
BananaRepublic
post Jun 1 2010, 11:46 PM
Post#3


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


KantWin,
Perhaps you already know that but at least for benefits of others:
Just because one has a 64-bit machine does not mean they must install 64-bit Access. In fact, if it is desired that the application continue to run 32-bit ActiveX control, it may be desirable to install 32-bit Access. With Office 2010, 32-bit are installed by default - you have to make explicit steps to install 64-bit versions.
Go to the top of the page
 
KantWin
post Aug 19 2010, 07:34 PM
Post#4



Posts: 581
Joined: 1-August 02
From: Alabama


I've been away from this for a while.
Are there any other options that are forthcoming to replace the common controls in 64 bit Office 2010?
Go to the top of the page
 
BananaRepublic
post Aug 19 2010, 07:44 PM
Post#5


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


Right now, no. I do not know if they have any plans upcoming, either. It's all up in the air. Hence, the recommend to install 32-bit Access even on 64-bit machines and thus continue to use 32-bit ActiveX controls.
Go to the top of the page
 
KantWin
post Dec 10 2010, 08:03 PM
Post#6



Posts: 581
Joined: 1-August 02
From: Alabama


I am 90% sure that when my organization rolls out Office 2010, it will have the 64 bit version of Office.
I would have no control over that.
That will break all of my databases, since they all use the TreeView.
I still have not found a solution.
Does anyone have any ideas?
Thank you.
Go to the top of the page
 
BananaRepublic
post Dec 10 2010, 08:12 PM
Post#7


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


Do they really have to have 64-bit Office? Even though it's great there's a 64-bit Office, Microsoft currently recommends and will install by default 32-bit. 64-bit installation should be basically restricted to those who actually need it.
If that is truly the case, an alternative is to look at 3rd party - I believe this is one such choice.
Go to the top of the page
 
AlbertKallal
post Dec 10 2010, 08:49 PM
Post#8


UtterAccess VIP
Posts: 2,490
Joined: 12-April 07
From: Edmonton, Alberta Canada


Just clarify a little bit here, the common dialog controls was never part of office. So it's not that office EVER had the common dialogs controls.
This is much an issue of using 32 or 64 bit controls that you choose to use with your application environment.
HAs a few others have noted here, I would be a REALLY surprised if your company is going to roll out a 64 bit version of office as opposed to 32 bits.
Keep in mind while the vast majority of machines today are running a 64 bit version of the operating system, the vast majority of us still continue to run the 32 bit edition of office on that 64 bit system.
Also keep in mind if any of your application uses the windows API, you'll have to rewrite those routines as you thus will being using the 64 bit version of the windows API.
This is explained here:
http://msdn.microsoft.com/en-us/library/ee...office.14).aspx
So you'll have to change some variable type declarations and function declarations to get just simple API calls to the 64 bit windows operating system to work if you use any existing API now.
So MORE then just ActiveX controls are going to break if you choose the 64 bit edition. So if your software is written to the 32 bit standard and uses the windows API, then either you rewrite parts of your code or you like best to adopt the compatible 32 bit version of office.
Is there any particular reason your company would not be rolling out the 32 bit version of office? I mean I assume they go through a quality assurance check, and test things like your code and the many other applications the organization has written will need testing here. To completely willy nilly out of the blue sky ignore all these issues tell me IT is putting you in an difficult situation (or they not doing their home work).
As noted, you better get a test mule and machine up running quick and to start testing out and rebuilding your windows APIs code NOW if they are a fact going to deploy the 64 bit version of office. If your information is correct and you do not have a choice in the version of office being deployed, then you're going to face more issues that go beyond that of just 32 ActiveX controls support.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
KantWin
post Dec 12 2010, 10:03 AM
Post#9



Posts: 581
Joined: 1-August 02
From: Alabama


Thank you all for your replies.
HAs I mentioned, I'm 90% sure that they will go with the 64 bit version of Office 2010.
Ocannot say for sure, since I am not in the know. I do not work for the "big IT" of the organization.
I develop a couple of Access databases that are in use scattered throughout the organization.
Really small potatoes as far as the "big IT" is concerned, to be honest, they are not concerned at all with what I do.
It does not matter to them if the deployment of 64 bit Office breaks what I do.
They do go through quite extensive QC checks. But, like I mentioned, what I do doesn't concern them.
The several hundred folks I have using my databases are concerned, obviously.
Go to the top of the page
 
BananaRepublic
post Dec 12 2010, 10:05 AM
Post#10


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


Interesting. I have to wonder why they think it's good idea to default to 64-bit office on such a large scale. As Albert noted, there is no requirement that Office be 64-bit simply because the machine or OS is 64-bit. (Here's a fun trivia: Visual Studio 2010 ships exclusively in 32-bit, even though you can use it to create 64-bit program!)
But did you look at the link I gave you? That should provide you the treeview control you need in 64-bit, I think.
Go to the top of the page
 
KantWin
post Dec 13 2010, 07:42 AM
Post#11



Posts: 581
Joined: 1-August 02
From: Alabama


I would have to wonder as well. But, they "know what's best", so I have to live with it.
tried to do a parallel install of 64 bit 2010, with my 2007 32 bit - that's not supported.
Otook a look at the link.
Do you have any experience with it?
I did not see, but does it require installation on the end-user computer as well? If so, that would be a solution that would not work fo
Go to the top of the page
 
BananaRepublic
post Dec 13 2010, 08:13 AM
Post#12


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


Yes, that's my experience - the literature made it clear that one cannot have both 32-bit and 64-bit Office 2010 installed side by side but it did give me an impression that it was OK to install different versions (e.g. 32-bit 2003/2007 and 64-bit 2010) but in my testing this also failed as well so I'm inclined to say it's a exclusive either/or proposition irrespective of versions.
would assume that it does require an installation since it's an ActiveX control; it could be automated (the installation). I honestly don't see how you could have any 3rd-party controls added without requiring some kind of installation - it's mandatory due to how ActiveX and underlying OLE/COM is architecture and needs to make the appropriate entries in the registry so it can be consumed by other programs. The only alternative I can see is to roll out your own Treeview using Access controls and faking it. (e.g. use a continuous subform and format the controls to look like a node, etc.)
Go to the top of the page
 
KantWin
post Dec 14 2010, 07:51 AM
Post#13



Posts: 581
Joined: 1-August 02
From: Alabama


Thanks again for the reply.
I'll experiment with the fake treeview.
I'm still not 100% clear as to WHY the common controls were removed from the 64 bit version.
Go to the top of the page
 
BananaRepublic
post Dec 14 2010, 08:49 AM
Post#14


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


None of us are.
ild-eyed baseless speculation: Microsoft is trying to wean people off COM & ActiveX in favor of .NET as the preferred development platform so they're using 64-bit migration as an opportunity to not migrate everything.
Please note that this is not fully consistent because it doesn't quite explain why would Microsoft have had invested into 64-bit VBA which is still solidly COM; after all there's already VSTO and PIAs so it's not that far off from moving away from VBA. I'd love to know the real reasons.
Go to the top of the page
 
AlbertKallal
post Dec 14 2010, 07:22 PM
Post#15


UtterAccess VIP
Posts: 2,490
Joined: 12-April 07
From: Edmonton, Alberta Canada


I should point out that the common controls were NEVER removed from the 64 bit version.
I am not aware how you can remove something that never was in the first place?
Now of course the above issue of something that never being removed does not help the fact that you don't have treeview. However, with the exception of the treeview, we now have a built in date picker, and in fact for the file dialog, we had a built in solution since 2003 that since 2003 that even works in runtime (and even works in runtime without having to set any additional references if you late bind the file dialog). Eg:
CODE
  Dim f    As Object
   Set f = Application.FileDialog(3)
   f.AllowMultiSelect = True
   f.Show
   MsgBox "file choosen = " & f.SelectedItems.Count

Using activeX controls was always a real issue with access since you don't have a installer that can install those dependencies along with your application. For this reason, most people have REALLY avoided activeX with access anyway (and you paying that price by not follwing that advice).
NOW toss in that MOST activeX controls are not being re-written by vendors and this results in a double hit. It is VERY simple that you are attempting to use some 32 bit software with some 64 bit software and you can't do that.
If you need to do this, then tell the correct people that they are choosing the wrong software for your needs. If they assume your needs are not important then there not much you can do except try to make yourself more important.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Go to the top of the page
 
KantWin
post Dec 18 2010, 04:43 PM
Post#16



Posts: 581
Joined: 1-August 02
From: Alabama


I have spent a few hours putting together a continuous form that replicates a treeview.
It seems to work pretty well.
Thank you for the idea.
Now, on to the ptrSafe changes. This should be fun, too.
I am not quite sure when it would be best to use the "Win64" constant, vs the "VBA7" constant.
Reading this just makes my head hurt.
Go to the top of the page
 
BananaRepublic
post Dec 18 2010, 05:03 PM
Post#17


Dungeon Cleaner
Posts: 1,504
Joined: 16-June 07
From: Banana Republic


To be safest, you would use both, but IMHO, VBA7 is adequate.
My reasoning is as following:
We should eventually migrate our API codes into a 64-bit compatible format, irrespective of whether we are actually running 32-bit Access or 64-bit Access. I simply want to get it out of the way as opposed to waiting until very last minute and end up pulling out hairs because I did not plan for any issues I may run into reformatting my code around 64-bit compatible APIs.
Secondly, the fact that we have a genuine pointer data type is very good thing and allow us to closely mirror the C++ definition of the API calls.
So, when we run 32-bit Access 2010, we do NOT have to write PtrSafe into our API codes. That is entirely optional. That remains true regardless whether we are running the 32-bit Access on a 64-bit OS/hardware or not. But why wait?
With Win64 constant, you're basically saying "run this code ONLY if we're running 64-bit Access." But when we write PtrSafe API codes, it will work equally well on 32-bit and 64-bit so there is no real reason why you need to change code between 32-bit OS and 64-bit OS other than adding PtrSafe, replacing Long with LongPtr where it is appropriate (not all of Longs should be replaced!) and using LenB() instead of Len() for where we size the structure. GroverParkGeorge has a sample illustrating all 3 things.
With VBA7, you are basically saying "run this code ONLY if we're using VBA7 which supports and understand new features of VBA7". Obviously, you can't take your PtrSafe'd API back to Access 2007 or earlier. VBA7 will work for that situation. Win64 will work equally well but for different reasons: There's no such thing as 64-bit Access 2007/2003/etc so those will be automatically excluded.
I hope that helps.
Go to the top of the page
 
datAdrenaline
post Dec 19 2010, 10:49 AM
Post#18


UtterAccess Editor
Posts: 17,923
Joined: 4-December 03
From: Northern Virginia, USA


It may be useful information to know, but in the quest to get an actual TreeView, from what I here, you can use .Net controls in a VBA/6 (VBA uses the VB6 engine) environment. You just have to create the .DLL and essentially wrap the .Net control to use Interop capability. I have NOT done this --- as of yet --- but it seems completely doable. You can then distribute the DLL with your app. The DLL will not need to be "installed" perse, just in the same folder as the db app.
Click Here for an article on Code Project where the concept of using a .Net control in a VB6 environment is illustrated.
Also, another article of interest in proceding with interop's is the one here from Microsoft: Interop Forms Toolkit 2.1
----
HAs a reminder, I have NOT proceded with any experimentation with this. I have used .Net's TreeView in C# and the Common Controls TreeView (.COM) one in A2007 and A2010 (32bit). I have not had the need (yet) to proceed with the wrapping of the .Net TreeView for use in A2010 (64-bit) .. but I bet the need will arive soon!
Go to the top of the page
 
KantWin
post Jan 14 2011, 07:15 PM
Post#19



Posts: 581
Joined: 1-August 02
From: Alabama


Well, I think I got it all sorted out. Almost.
I'm using some late binding, for the ribbon code, and with the #VBA7 check, I can reference the correct Office Object library.
I'm using a continuous form that very closely replicates the treeview.
The database can now go easily between Office 2007 and Office 2010, including the 64 bit version - as long as it's an accde file.
Now, the problem comes in when it's an accde file.
I think I'm stuck making 2 different versions.
I wish I could trap what version it is, to give a more appropriate message.
If I use an accde that was made with Office 2007, and I run it on the Office 2010 64 bit, the message tells you to get Access 2010 32 bit.
That's not what I want - I want it to tell my users to use the 64 bit accde, which is in the same folder as the 32 bit version.
But, I don't think it gets to a point where I can run my code to check that, and customize the message.
Am I missing something still?
Go to the top of the page
 
AlbertKallal
post Jan 14 2011, 08:31 PM
Post#20


UtterAccess VIP
Posts: 2,490
Joined: 12-April 07
From: Edmonton, Alberta Canada


U r correct that no mix of 32/64 accde is allowed . U can do this with mdb or accdb, but accde must match the bit version.
Should be able to deploy the64 2010 runtime. Also while u r burning a trail here , we all r watching this since this is something we all will have to do in the near future as 64 bits becomes common .
lso someone could cook up a tree view using .net that wraps up something and exposed the net treeview as an com object.
(Hope this post comes out ok - doing this on my new windows 7 phone)
Go to the top of the page
 
2 Pages V  1 2 >


Custom Search
RSSSearch   Top   Lo-Fi    23rd August 2017 - 02:33 PM