>> If you using the DataEnvironment then you are using ADO. The dbGrid control
>> was originally DAO (and contains some DAO 'roots'). The new control can use
>> ADODB or DAO Recordsets.
I'm not using DataEnvironment. I'm using DAO
There are what i'm doing on the test project.
0. dbgrid32cx version 9813
1. I place "data control" on the form
2. Connect it to databse setting "databasename" and "RecordSource"
3. then dbgird on then form and connect it to "data1" setting "dataSource"
4. Right-click dbgrid and do "retrieve field" - captions of columns are filled
5. Run Application - no data in the grid, and no captions.
No code. This combination works with old version of ocx
6. Stop application. Right-click dbgrid and do "Clear field"
7. Run Application - there are data in the grid :)
The old version of "dbgrid32cx" no. 8104 shows correct data in both situation.
Adding dbgrid1.refresh does'n help.
> >> If you using the DataEnvironment then you are using ADO. The dbGrid control
> >> was originally DAO (and contains some DAO 'roots'). The new control can use
> >> ADODB or DAO Recordsets.
> I'm not using DataEnvironment. I'm using DAO
Ha.
I'm a dufus. I read your reply and my brain translated into saying you were
using DataEnvironment. Sorry.
> There are what i'm doing on the test project.
> 0. dbgrid32cx version 9813
[quoted text clipped - 9 lines]
> The old version of "dbgrid32cx" no. 8104 shows correct data in both situation.
> Adding dbgrid1.refresh does'n help.
My reply was based on the following condition: (not saying this is you, only
what can occasionally cause this problem, and why I gave the silly answer I
did.)
Say a developer creates a simple project with one Form, a couple of action
buttons, and a DBGrid. And within the design-time Property settings define
the database name, etc. During runtime - data (captions, cells) - may behave
strangely with various retrievals/clear/re-populate actions invoked by the
buttons causing data to appear and disappear, forcing one to "micro-manage"
the bounding. (It is as though the control is always one step behind.)
But that is not be the case here, and I apologize for the misunderstanding.
(I also have mostly used DE or straight ADO for "data-binding" and this also
colored my thinking. But enough whinning. I apologize for sending you off
track. lol)
There is a difference between the old version and the new version. Simply
put the difference is the control no longer supports a "partial bounded"
mode.
Try this:
During design when you right-click "Retrieve Fields", then right-click again
and select "Edit". Then delete, add, resize, ... Then select Properties and
configure.
Then run your application. You should see whatever you designed.
Alternately go back and "Clear Fields", and like what you experienced - a
"default" view will appear.
ie, you can't have it both ways it must be either "unconfigured" or "fully
configured".
Also to be on the safe side - destroy any "oca" files you might have hanging
about. VB will recreate these as needed.
hth
-ralph
Ralph - 22 Jun 2009 16:20 GMT
<snipped>
> There is a difference between the old version and the new version. Simply
> put the difference is the control no longer supports a "partial bounded"
> mode.
Substitute "unbound" for "partial bounded" for accuracy.
bartek - 22 Jun 2009 19:28 GMT
> (I also have mostly used DE or straight ADO for "data-binding" and this also
> colored my thinking.
We have created this project before ADO (this is the reason I told before
about access 97) and has worked for 10 years... till now :(
>Try this
> During design when you right-click "Retrieve Fields", then right-click again
> and select "Edit". Then delete, add, resize, ... Then select Properties and
> configure.
> Then run your application.
I know how to set properties. This it not a problem.
You can see the efect on
http://www.vbforums.com/showthread.php?p=3541870#post3541870
But Your words about Properties allow me to find the bug....:)... which I
cannot correct :(
"Retrieve fields" takes information about columns and fill the the Columns
collection in PropertyPages, but do not fill the "DateField" for each column,
and more... when I manualy set DateField for Column0 and press "Apply" or
"OK" or change the column the information in DateField dissapear.
Also in my 10 years old project all information about "Columns-DateField"
association has dissapeared. So, this is the problem: With new version of OCX
I'm not able to set the DateField for columns :(
> Also to be on the safe side - destroy any "oca" files you might have hanging
> about. VB will recreate these as needed.
I've deleted old oca, but nothing happened after re-creation.
I also find that this is not "my system problem" because i've innstaled a
new system with new VB instance + VBSP6 and everything is the same.
thanks in advance
bartek
Ralph - 22 Jun 2009 19:46 GMT
> > (I also have mostly used DE or straight ADO for "data-binding" and this also
> > colored my thinking.
[quoted text clipped - 25 lines]
> I also find that this is not "my system problem" because i've innstaled a
> new system with new VB instance + VBSP6 and everything is the same.
Yeah, again I'll apologize for my misunderstanding, And I certainly didn't
mean to infer you didn't know how to set properties, just wanted to know
what would happen if you "fully" bound all the information during design
time.
If I understand you correctly this time - everything seems to work, except a
"Date Field". I can't test it at the moment but I'll go back and piddle when
I get the chance.
I vaguely remember (now that you have jogged my memory) there were a number
of howls of complaint with the new control from those using DAO. I bet there
is an article or two on the web talking about this very issue. That is if
you can find them amongst the VB.Net chatter, and people confusing the
control name. lol
Sry I wasn't of more help.
-ralph
bartek - 23 Jun 2009 14:23 GMT
> I vaguely remember (now that you have jogged my memory) there were a number
of howls of complaint with the new control from those using DAO.
I've found a lot of information about this new package od controls, but only
that they've stoped working in VBA project after client's system update (In
fact I've got this in one of my clients computer), so this means for me that
we should change the version of OCX to new one, but .....
Ralph, thanks for your Help
I'll wait for "cumulative pack - v3" :)
Bartek
Mauro Marini - 03 Aug 2009 12:25 GMT
Hi Bartek.
Unfortunatly i have exactely the same problem... and i cannot solve it. The
same happend to me a couple of months ago. I cannot be sure cause at that
time i've done a lot of thing to find a solution, but seems to be that using
the fie "... .reg" contained in the "old controls" folder of the MS VB6 PRO
CD, it was working. Today, apparently without any reason, the problem is
camed out again... But the solution i was talking about befor doesn't work!
And i am a bit disperate cause I have a lot of important project to be
mantained... a I cannot change controls... NOT NOW.
Without a solution to this problem I cannot compile new running versions of
my programs...
Did you find anything else?
You says that the probelm came with the installation of cumulative patches
for VS6.... did you try to uninstall this update?
Thank you.
Regards.
Mauro Marini.
StarNet s.r.l.
Rubano - Padova - Italia
> > I vaguely remember (now that you have jogged my memory) there were a number
> of howls of complaint with the new control from those using DAO.
[quoted text clipped - 7 lines]
> I'll wait for "cumulative pack - v3" :)
> Bartek
bartek - 10 Sep 2009 13:44 GMT
Hi,
>> You says that the probelm came with the installation of cumulative patches
for VS6.... did you try to uninstall this update?
You cannot uninstall this patch.
I have one special computer with VB6.0 without this patch to compile old
projects, I'm waiting for "cumulative patch v. 03" :) and praying for correct
working one my clients computers ;)
I'll post something here if I find the solution.
Bartek