strange problem with binary compatibility
Eduardo
am coding an upgraded version of it, and I want to keep binary
compatibility.
I added one property and some features with no problem.
But now I have a problem. Im my control I have this code in a sub:
Dim mc as MyControlName
Set mc = FormName.Controls.Add ("MyProjectID.MyControlName",
"NewControlName")
It used to work well until now. Now it Raises error 13 (wrong data type)
May be I changed Private/Public for some APIs declarations or data types
(needed for the API calls), all in two Modules that I've been working on.
But I didn't change anything in the control interface.
The OCX compile well, without any problem, with binary compatibility. When I
use the OCX in a project, I works fine, no problem.
The problem is when the Usercontrol project is running in the IDE, when I
test the Usercontrol in a group project. It raises Error 13 at that line
when running in the IDE and the compatibility is set to binary.
I didn't touch the declaration, it always have been "Dim mc as
MyControlName".
I tried "Dim mc as Control", "Dim mc as Object", "Dim mc as Variant", but
all have problems (It doesn't cause Err 13 but others errors because it says
it can't find control properties mc.PropertyName.
Anyway, it wouldn't be necessary any declaration change anyway (I did that
just for testing).
Before, when I added the new property I had the same situation (this
problem); and I closed VB a couple of times, compiled the OCX a couple of
times, used it in a new project, and, I don't now how or why, the problem
was solved.
But now, I tried everything, unregister the OCX, reboot Windows, test the
project in another Windows (the problem happened), installed vb6sp6, all I
could think about, and the problem is not solved.
I could set it to "project compatibility" in the IDE, when coding and
testing, and change it to "binary compatibility" just before compiling, but
it is very annoying, I would like to know what happen and how to solve it.
Thanks in advance for your time.
Regards,
Eduardo
Eduardo
My control adds an instance of itself to a form with the code:
Dim mc as MyControlName
Set mc = FormName.Controls.Add ("MyProjectID.MyControlName",
"NewControlName")
The project is set to binary compatibility with an old OCX version.
The OCX compiles OK, no complaint.
In a client project, the OCX works well (seemingly).
In the IDE, that line used to work fine. But now (only when running in the
IDE) it raises error 13, "data type mismatch".
The control is actually added to the form, but the line returns with Error
13.
if I put (after that line, with an "on error resume next"):
Debug.Print TypeName (FormName.Controls ("NewControlName"))
it writes as expected, "MyControlName"
If I set the compatibility of the project to "project compatibility", the
problem disappear.
Any clue?
Thanks.
"Eduardo" <m...@mm.com> escribió en el mensaje news:gbgnm7$5k1$1...@aioe.org...
Eduardo
The problem was caused by the new property.
I am attaching here an example so anyone interested can see it.
It is a new project UserControl ActiveX, with name MyProject.vbp.
There is a second project to test it, ProjectTest.vbp.
So please load the project group, Group1.vbg
MyProject.vbp was compiled with only one property, with name "Property1".
Then, the project compatibility was set to binary with the reference to the
compiled MyProject.ocx.
After that, I added a new property with name "NewProperty".
After adding the new property, if you try to add an instance of the control
dinamically to a form, you get error 13. If you remove the property, then it
works fine.
Nevertheless, if you compile the OCX, it compiles with no complaint.
Any idea?
PS: when the first time I added the property and found this problem, I don't
remember exactly what magic trick I did (recompile a couple of times, etc),
and managed this to work, but I can't figure now what to do to make it work
with the new property and with binary compatibility.
Thanks, Eduardo.
"Eduardo" <m...@mm.com> escribió en el mensaje news:gbgp66$c74$1...@aioe.org...
Eduardo
In my example, in the procedure AddToFormX of the UserControl, changing "Dim
c As MyControl" to "Dim c As Control", the error 13 doesn't arise (also with
"as Object" and "As Variant").
But there is then another problem.
In my control I have several Friend properties. So, If you are in the
example I posted, add this property:
' Declarations:
Private p3 As String
' Procedures
Friend Property Get Property3() As String
Property3 = p3
End Property
Friend Property Let Property3(ByVal vNewValue As String)
p3 = vNewValue
End Property
Then, after the line "FormX.Controls("DynamicallyAdded_MyControl").Visible =
True", add this:
c.Property3 = "A"
Then you get error 438, "the object doesn't allow this property or method".
If the property is defined as "Public" there is no error.
But unfortunately, I have several properties that must be Friend, because I
use then only internally (and I don't want them to be exposed to the user).
I am already convinced that it is a bug in VB6.
The point is what to do, how to deal with this.
The only thing I can do is, as I said before, to set the compatibility to
"project compatibility" while I am coding and debugging, and set it back to
binary just before compiling.
But it is dangerous, because if I forget to change that before any
compilation, I mess all up.
Thanks,
Eduardo.
"Eduardo" <m...@mm.com> escribió en el mensaje news:gbh94d$89l$1...@aioe.org...
Eduardo
"Property3" is new in the sample project because I didn't include a Friend
property in the first compilation, but in my project are all old ones and
the problem arises too.
"Eduardo" <m...@mm.com> escribió en el mensaje news:gbhejk$r1s$1...@aioe.org...
Ken Halter
> PS: the properties defined as "Friend" are all old ones.
> "Property3" is new in the sample project because I didn't include a Friend
> property in the first compilation, but in my project are all old ones and
> the problem arises too.
Boy... it's been quite a while since I last logged on to this group...
For your Binary Compatibility issues, see:
Binary Compatibility
http://www.vbsight.com/BinaryComp.htm
... you'll, note the page includes ways to prevent your specific problem. In
a nut shell, "binary compatibility" with a certain component applies only to
the public members of that specific component. When you add new publics to
your "release" version, the file you're using for compatibility needs to be
updated as well... Otherwise, VB's generating new IIDs for each public,
every time you compile.
If you haven't deployed any previously compiled versions yet, you're still
in good shape.
imo, the best thing to do at this point would be to unregister the existing
component and delete it, as well as the file you're using for compatibility.
Also delete any (and all) OCA files you come across. They're the most likely
cause of your error 13's.
...about the error 438...
The most likely cause is... Controls are considered Private object
modules... Friend properties and methods can be used only from within their
own project. You'll never be able to call a Friend method or set a Friend
property in an OCX that's been dropped on a form that's not included in the
OCX project itself.
Basically, Friend = Public within its own project. Very similar to adding a
Public to a BAS module.
--
Ken Halter
Part time groupie
Eduardo
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> escribi� en el mensaje
news:uAJWeSLJ...@TK2MSFTNGP03.phx.gbl...
> "Eduardo" <m...@mm.com> wrote in message news:gbherh$roi$1...@aioe.org...
>> PS: the properties defined as "Friend" are all old ones.
>> "Property3" is new in the sample project because I didn't include a
>> Friend property in the first compilation, but in my project are all old
>> ones and the problem arises too.
>
> Boy... it's been quite a while since I last logged on to this group...
>
> For your Binary Compatibility issues, see:
>
> Binary Compatibility
> http://www.vbsight.com/BinaryComp.htm
I have read this, and thank you, I realized about some situations with
binary compatibility.
> ... you'll, note the page includes ways to prevent your specific problem.
But I think you are wrong here, the page doesn't discuss my problem.
>In a nut shell, "binary compatibility" with a certain component applies
>only to the public members of that specific component. When you add new
>publics to your "release" version, the file you're using for compatibility
>needs to be updated as well... Otherwise, VB's generating new IIDs for each
>public, every time you compile.
That's what I learned reading your page, so even when it is another
situation (not the problem that I'm exposing here), I thank you for that
information that will prevent me from making mistakes.
>
> If you haven't deployed any previously compiled versions yet, you're still
> in good shape.
That's the point, many people are using the previous release version of my
ocx already.
But since I found this problem, I didn't release any version, I'm still
working in the upgrade.
>
> imo, the best thing to do at this point would be to unregister the
> existing component and delete it, as well as the file you're using for
> compatibility. Also delete any (and all) OCA files you come across.
> They're the most likely cause of your error 13's.
Of course the error will not arise if there is no compatibility, but I want
compatibility with the previous version I released to my customers.
>
> ...about the error 438...
>
> The most likely cause is... Controls are considered Private object
> modules... Friend properties and methods can be used only from within
> their own project. You'll never be able to call a Friend method or set a
> Friend property in an OCX that's been dropped on a form that's not
> included in the OCX project itself.
I guess that you didn't downloaded the sample project that I attached to
other message, because the situation is that I'm using the Friend properties
from inside the ocx.
Basically, to comunicate one instance of the Usercontrol to another (inside
the ocx).
>
> Basically, Friend = Public within its own project. Very similar to adding
> a Public to a BAS module.
Yes.
It seems to me, that (with binary compatibility set) when the interface is
not changed, adding an instance of the Usercontrol at runtime (from inside
the Usercontrol's project) VB consider the Usercontrol as of the same
project, so object type is the same and Friend procedures are visible. But
when anything of the interface is changed (adding a property, for example),
VB considers the instance of the Usercontrol added at runtime as another
type of object.
I really don't understand why because I don't know how VB works internally.
Please, if you want to undestand this problem, read all what I wrote
(specially from my third post and ahead) and run the sample I attached to my
third post.
For the time being, I decided to set the compatibility to "project
compatibility" while developing, and set it to "binary compatibility" just
before compiling.
Ken Halter
>
>> ... you'll, note the page includes ways to prevent your specific problem.
>
> But I think you are wrong here, the page doesn't discuss my problem.
Well... one of the problems you mentioned was that adding a new property
causes error 13's. That's because that new property needs to be in the
compatibility model, too... Plus, you need to recompile while pointing to
that new "model", so the internal compatibilty flags/pointers/etc, are set
correctly.
>> If you haven't deployed any previously compiled versions yet, you're
>> still in good shape.
>
> That's the point, many people are using the previous release version of my
> ocx already.
> But since I found this problem, I didn't release any version, I'm still
> working in the upgrade.
Do you have a registry cleaner handy? I use the old Microsoft RegClean. It's
available on ZDNet downloads... it causes a few problems with specific MS
Office installations, but imo, it's still work using.
If you unregister ALL copies of that OCX and either delete them or add them
to a zip file (VB can't know they exist, or it'll attempt to use them)...
then, search your drive for OCA files, delete all of them (VB will happily
recreate them as required)... run RegClean. If you've never used RegClean,
don't be surprised at the size of the "Undo" file. It'll probably be fairly
huge and contain tons of registry junk that's no longer required...
Now, carefully copy ONLY the version of that OCX you shipped to the "Compat"
folder (or what ever you've named it). This is the most important version of
your OCX, so forget all the rest.
Add the new property, making sure VB is pointing to that shipped OCX.
When it's done, exit VB (to avoid error 70's), rename the "shipped" OCX to
something else and place the new OCX in the "Compat" folder.
Restart VB, recompile without changing anything... now the OCX's internals
should be setup correctly to recognize and maintain compatibility with your
new OCX. Think of it like a "hand shake"... you're telling VB to maintain
compatibility with a specific OCX that exposes specific publics.
Note that my add-in (ComGuard) does "all of the above" for you.
>> imo, the best thing to do at this point would be to unregister the
>> existing component and delete it, as well as the file you're using for
>> compatibility. Also delete any (and all) OCA files you come across.
>> They're the most likely cause of your error 13's.
>
> Of course the error will not arise if there is no compatibility, but I
> want compatibility with the previous version I released to my customers.
Yeah, I didn't mean to reset compatibility... just get rid of obsolete OCA
files and make sure there aren't any "broken" versions of the OCX anywhere
that VB can find them.
OCA files are the root of all evil <g> They're temporary typelibs that
really should be deleted by VB when it's shut down... making changes in an
OCX without deleting the OCA can cause a lot of "hard to trouble-shoot"
problems.
>> ...about the error 438...
>>
>> The most likely cause is... Controls are considered Private object
>> modules... Friend properties and methods can be used only from within
>> their own project. You'll never be able to call a Friend method or set a
>> Friend property in an OCX that's been dropped on a form that's not
>> included in the OCX project itself.
>
> I guess that you didn't downloaded the sample project that I attached to
> other message, because the situation is that I'm using the Friend
> properties from inside the ocx.
> Basically, to comunicate one instance of the Usercontrol to another
> (inside the ocx).
No... I didn't download the sample. I'll give it a try shortly and let you
know if I see anything obvious.
>>
>> Basically, Friend = Public within its own project. Very similar to adding
>> a Public to a BAS module.
>
> Yes.
>
> It seems to me, that (with binary compatibility set) when the interface is
> not changed, adding an instance of the Usercontrol at runtime (from inside
> the Usercontrol's project) VB consider the Usercontrol as of the same
> project, so object type is the same and Friend procedures are visible. But
> when anything of the interface is changed (adding a property, for
> example), VB considers the instance of the Usercontrol added at runtime as
> another type of object.
VB's probably attempting to use an obsolete OCA file... they really are a
pain in the....
> I really don't understand why because I don't know how VB works
> internally.
>
> Please, if you want to undestand this problem, read all what I wrote
> (specially from my third post and ahead) and run the sample I attached to
> my third post.
>
> For the time being, I decided to set the compatibility to "project
> compatibility" while developing, and set it to "binary compatibility" just
> before compiling.
Project Compatibility will ruin your day <g> If you compile with "Project
Compatibility" It's exactly the same as "No Compatibility". "Project
Compatibility" does nothing but retain the design-time references for you,
so you don't need to re-add them every time you attempt to debug the OCX.
How To Use Project and Binary Compatibility
http://support.microsoft.com/kb/161137/en-us
But, anyway... I'll try the sample and see if anything "sticks out"
Eduardo
One could consider that changing the reference compatibility file to the
last compiled ocx, one with the new properties added, the problem would not
arise. But it does.
One could think that doing so, VB doesn't know any more about the first
version's interface, but it seems that the old interface is still stored in
the Windows registry, even if the old ocx was unregistered and deleted.
Eduardo
I start from the last line:
> But, anyway... I'll try the sample and see if anything "sticks out"
I think that you should understand well the situation, so you have to see it
for yourself if you want to understand this, at least as a curiosity.
I am talking about the compatibility from inside the ocx and at design time.
> Do you have a registry cleaner handy? I use the old Microsoft RegClean.
> It's available on ZDNet downloads... [...]
I used to use Regcleaner in the past, now I am using CCleaner (the registry
utility). But I will find and download the old Ms Regcleaner as you said
because I think that CClenaer doen't delete all the unused interface keys.
> Note that my add-in (ComGuard) does "all of the above" for you.
I tried to download it but your page says that it is not longer available
(http://www.vbsight.com/ComGuard.htm#Download)
> Project Compatibility will ruin your day <g> If you compile with "Project
> Compatibility" It's exactly the same as "No Compatibility". "Project
> Compatibility" does nothing but retain the design-time references for you,
> so you don't need to re-add them every time you attempt to debug the OCX.
>
> How To Use Project and Binary Compatibility
> http://support.microsoft.com/kb/161137/en-us
I think that "project compatibilty" may be useful in some situations.
For example: If I decided to delete or change a property (o several ones) or
I deleted a member from an Enum. I changed the compatibility there, there is
not more "binary compatibility" possibility. If I compile the new ocx
without any compatibilty, the clients will have to delete the old version
control from every form that they had them, and insert the new one. But if I
compile it with "project compatibility", they will be prompted to upgrade to
the new version but they don't have to replace all the instances of the
control(s) placed on the forms.
> Add the new property, making sure VB is pointing to that shipped OCX.
> When it's done, exit VB (to avoid error 70's),
I never got that error, or I don't remember...
Thanks,
Eduardo
Ralph
"Eduardo" <m...@mm.com> wrote in message news:gc3itp$qlv$1...@aioe.org...
> Hi Ken, and thank you for your interest.
>
> I start from the last line:
>
> > But, anyway... I'll try the sample and see if anything "sticks out"
>
> I think that you should understand well the situation, so you have to see
it
> for yourself if you want to understand this, at least as a curiosity.
> I am talking about the compatibility from inside the ocx and at design
time.
>
You not listening, or rather not "reading" what Ken is telling you. Go back
and re-read his explanations and suggestions carefully, and then do it that
way. Period.
You are having the problems because you are not doing it the correct way.
Forget about VB doing something magical behind your back. All the magic is
confined from the chair to the keyboard.
-ralph
Eduardo
I have read and "listened" caresfully. Please be kind and don't get involved
if you don't understand something, please.
"Ralph" <nt_cons...@yahoo.com> escribi� en el mensaje
news:ubnlXdQJ...@TK2MSFTNGP02.phx.gbl...
Eduardo
because it seems that you know what I listened and what I didn't listen,
what I did and what I didn't do.
If you already understood all this situation (as it seems to be the case
because you criticized me), please then point me exactly what particular
thing I should have done that I didn't do.
Thanks,
Eduardo
"Ralph" <nt_cons...@yahoo.com> escribi� en el mensaje
news:ubnlXdQJ...@TK2MSFTNGP02.phx.gbl...
Ralph
"Eduardo" <m...@mm.com> wrote in message news:gc46mj$4pe$1...@aioe.org...
> What are you talking about?
>
> I have read and "listened" caresfully. Please be kind and don't get
involved
> if you don't understand something, please.
>
Yes I was harsh and sarcastic. And I meant to be harsh and sarcastic to
shock you into stopping what you are doing, revaluate what you need to do,
and listen when someone gives you advice.
You CAN update an ActiveX component by *Adding* elements to a published
interface.
VB was designed to hide COM issues away from the developer by using its own
internal "COM builder" for lack of a better phrase. This allows a developer
to create COM components almost transparently, without all the bookkeeping
and coding required by other languages/platforms at the time. Unfortunately
this convenience comes at a price. You have to deal with the VB COM
"builder". Not doing so can lead to behavior which on the surface may seem
bizzare or exceptional. It is not. It is simply a sign that the developer is
not using VB in a way to produce the required result.
Ken gave you an excellent, detailed step by step, solution to your problem.
Take time to listen to him.
-ralph
Eduardo
On the other hand, I'm not saying that Ken didn't provide a good explanation
of binary compatibility.
But the situation that I have is specific, I made all the things for
"normal" compatibility situations and I still have the problem.
I would like to know if you understood what the situation that I'm talking
about is. If not, I'll repeat it one more time if you want.
I undestand the compatibility rules (as explained in Ken's page).
I deleted all and every .oca file, deleted or renamed all ocx versions, and
also have run the old MS Regclean. Then, opened the project and changed the
reference file to the las compilation. The problem still arise.
But do you know what problem I'm talking about is?
You says that I didn't pay attention to something, but to what specific
thing you think I did't pay attention?
"Ralph" <nt_cons...@yahoo.com> escribi� en el mensaje
news:eZkVofWJ...@TK2MSFTNGP03.phx.gbl...
Ken Halter
> On the one hand, thank you for your explanantion.
Ok... I didn't have much time, but I did notice (at least in the zip file),
the file you're using for compatibility isn't separate from the "release"
version... in other words, it seems the "model" is getting over-written each
time you compile. That can cause problems all by itself.
After I unregistered and deleted the OCX, the project group runs without the
error 13. As soon as I can squeeze a bit more time, I'll try it with the
OCX, but it'll be in it's own "Compat" folder until a new version is
compiled.
If you move/delete or rename an ActiveX Component, make double-sure to
unregister it first. Otherwise, the OS may try and update the registry after
your change.... that happened to us quite a while ago... the test guy simply
deleted the "old" version, sending it to the recycle bin and put a new
version in its place.
The OS, while trying to "help", updated the registry to point to the
recycle-bin, so *that* component was in use and not the updated version...
the bug was purely cosmetic so no one complained... that is, until the
customer decided to empty the recycle bin, which deleted the only version VB
knew about.
To prevent this, we created a vbscript that adds the registry entries found
in....
Register/Unregister Active X Components from the Context Menu
http://www.freevbcode.com/ShowCode.asp?ID=1370
...which allows our us to double-click a dll/ocx to register, or right-click
and select Unregister, right from Windows Explorer.
We tell them... never delete/rename or move a DLL or OCX without
unregistering it first.
Since VB relies almost entirely on the registry, keeping the registry clean
is a very important "chore" that often gets overlooked. Since it can cause
so much grief, it's best to get in the habit of doing all you can to keep it
clean.
...once you find your "perfect method", write the procedure down somewhere
and follow those exact steps, every single time.
Eduardo
Thanks.
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> escribió en el mensaje
news:ukLeqwaJ...@TK2MSFTNGP06.phx.gbl...
Eduardo
news:ukLeqwaJ...@TK2MSFTNGP06.phx.gbl...
> "Eduardo" <m...@mm.com> wrote in message news:gc616v$8g3$1...@aioe.org...
>> On the one hand, thank you for your explanantion.
>
> Ok... I didn't have much time, but I did notice (at least in the zip
> file), the file you're using for compatibility isn't separate from the
> "release" version... in other words, it seems the "model" is getting
> over-written each time you compile. That can cause problems all by itself.
Because that was a sample and was compiled just one time.
>
> After I unregistered and deleted the OCX, the project group runs without
> the error 13.
Yes, because it doesn't have compatibility any more.
>As soon as I can squeeze a bit more time, I'll try it with the OCX, but
>it'll be in it's own "Compat" folder until a new version is compiled.
Better don't you try with the ocx, do it for yourself in the way that you
think it is proper in a new project.
You have the example of what kind of code causes the problem there in my
sample project.
1) You need to make a project with code like the sample.
2) For this code you need to uncheck "Remove information about unused
ActiveX Controls" in the project properties.
3) Compile.
4) Set the binary compatibility to a copy of the compiled file.
5) Add a property.
That's it. You'll get the error when the project runs in the IDE.
Eduardo.
Ken Halter
> You have the example of what kind of code causes the problem there in my
> sample project.
>
> 1) You need to make a project with code like the sample.
Actually, I give up. It's certainly not worth any more of my time. The
mechanism isn't "magic". It doesn't work for some people and not others.
Eduardo
You never knew what i was talking about.
Schmidt
"Eduardo" <m...@mm.com> schrieb im Newsbeitrag news:gd0gv7$fea$1...@aioe.org...
> You never knew what i was talking about.
As I see it, you are much - much too fast with that
statement (not only in your conversation with me).
I mean, every developer has this "phase" in his live
where he thinks he's the greatest programmer in
the universe (myself included of course) - in your
case I think, we need to wait some time, until the
"reality-check" you currently experience in this group
has settled down a bit. ;-)
Olaf
Eduardo
news:uG3bakZL...@TK2MSFTNGP03.phx.gbl...
>
> "Eduardo" <m...@mm.com> schrieb im Newsbeitrag news:gd0gv7$fea$1...@aioe.org...
>
>> You never knew what i was talking about.
> As I see it, you are much - much too fast with that
> statement (not only in your conversation with me).
At least in this case, i'm very sure.
We would have to analize other cases where you say i did that. For example,
in the "Property bag/load resources" thread(s), at the end you understood
the situation, but most of the people that participate (and you at first)
didn't. Except expvb and you (at last), the other people criticized me but
they didn't understand what i was talking about.
> I mean, every developer has this "phase" in his live
> where he thinks he's the greatest programmer in
> the universe (myself included of course)
Are you in this phase?
I see that you are not able to accept a correction or someone else idea as a
possible valid option.
I try to be as humble as i possible can, but i don't accept bullshit from
people that don't have a clue on what the problem i'm talking about is (i'm
not refering to you with this).
>- in your
> case I think, we need to wait some time, until the
> "reality-check" you currently experience in this group
> has settled down a bit. ;-)
It depends if i have the time and the like to participate and help.
For me, to write in English is a step of difficulty because it's not my
mother language.
I decided to post these "difficult" questions here because may be there are
more experienced programmers of ActiveX controls than in my mother language
are.
Helping in these usenet groups is like a hobby (and an addiction). I used to
have it in the past.
Anyway, i like to help people.
I think that the problem is that when some newcomer's nick appear, you soon
assume that he or she is a newbie.
And also: "if he is asking questions, he must be a newbie".
I don't have shame to ask if i have a problem or i have to do something and
someone else can provide some help. I don't know everything.
What irritate me is the people that don't really undestand the situation,
and say anything that it is not the answer. And worse if they pretend that
they are the yoda master.
Peace.
Schmidt
"Eduardo" <m...@mm.com> schrieb im Newsbeitrag news:gd0vk9$233$1...@aioe.org...
> At least in this case, i'm very sure.
Another rule you will have to learn as it seems -
don't blame the tool... ;-)
> We would have to analize other cases where you say
> i did that. For example, in the "Property bag/load
> resources" thread(s), at the end you understood
> the situation,
No, already in my second post - and I was sending basically
the same recommendations to you with endless endurance
until you understood finally what I meant in that second post.
> > I mean, every developer has this "phase" in his live
> > where he thinks he's the greatest programmer in
> > the universe (myself included of course)
>
> Are you in this phase?
Hmm - what do you think?
> I see that you are not able to accept a correction or someone
> else idea as a possible valid option.
So you are not here for help, but to correct people
who try to help you - and it is of course not you who
cannot express your problem-domain somewhat better,
nahh - all others simply aren't able to follow you.
> >- in your case I think, we need to wait some time, until the
> > "reality-check" you currently experience in this group
> > has settled down a bit. ;-)
>
> It depends if i have the time and the like to participate and help.
> For me, to write in English is a step of difficulty because it's not
> my mother language.
Another reason, why you shouldn't be that fast with your
"you all don't understand my logic" - if you know, that your
language-skills lack some perfection, then I would be more
careful with such statements - that really doesn't come across
very polite, if you know by yourself as it seems, that you maybe
meant one thing and possibly wrote something other - which
could have been misunderstood.
> I decided to post these "difficult" questions here because may
> be there are more experienced programmers of ActiveX controls
> than in my mother language are.
Why do you hesitate to write, "than I am currently". ;-)
> I think that the problem is that when some newcomer's
> nick appear, you soon assume that he or she is a newbie.
No, most regulars here normally have no problem, to deduce that
from the "posting-style" - may I ask, how old you are - somewhere
between 20 and 30? ...or am I totally wrong with my assumption.
Olaf
Eduardo
>
> "Eduardo" <m...@mm.com> schrieb im Newsbeitrag news:gd0vk9$233$1...@aioe.org...
>
>> At least in this case, i'm very sure.
> Another rule you will have to learn as it seems -
> don't blame the tool... ;-)
Kid, i have to learn rules, but you...
All arrogants can kiss my ass. Is that clear?
>> We would have to analize other cases where you say
>> i did that. For example, in the "Property bag/load
>> resources" thread(s), at the end you understood
>> the situation,
> No, already in my second post - and I was sending basically
> the same recommendations to you with endless endurance
> until you understood finally what I meant in that second post.
You are not honest. I don't mind.
>> > I mean, every developer has this "phase" in his live
>> > where he thinks he's the greatest programmer in
>> > the universe (myself included of course)
>>
>> Are you in this phase?
> Hmm - what do you think?
>
>> I see that you are not able to accept a correction or someone
>> else idea as a possible valid option.
> So you are not here for help, but to correct people
> who try to help you
Of couse kid, if I see that they are wrong, i also help.
>- and it is of course not you who
> cannot express your problem-domain somewhat better,
> nahh - all others simply aren't able to follow you.
Is that difficult to say: "i don't understand you?"
>
>> >- in your case I think, we need to wait some time, until the
>> > "reality-check" you currently experience in this group
>> > has settled down a bit. ;-)
>>
>> It depends if i have the time and the like to participate and help.
>> For me, to write in English is a step of difficulty because it's not
>> my mother language.
> Another reason, why you shouldn't be that fast with your
> "you all don't understand my logic" - if you know, that your
> language-skills lack some perfection, then I would be more
> careful with such statements - that really doesn't come across
> very polite, if you know by yourself as it seems, that you maybe
> meant one thing and possibly wrote something other - which
> could have been misunderstood.
My language skills are enough for me to understand. If i don't, i ask (i did
it a couple of times).
I read much English, i write no so much.
I don't have time to loose with this conversation, so i quit.
Good luck.
Proverbs 16:18
Pride goeth before destruction, and an haughty spirit before a fall.
Eduardo
>> I decided to post these "difficult" questions here because may
>> be there are more experienced programmers of ActiveX controls
>> than in my mother language are.
> Why do you hesitate to write, "than I am currently". ;-)
Yes, that was my hope. I see that i found something else.
Schmidt
"Eduardo" <m...@mm.com> schrieb im Newsbeitrag news:gd18p5$ua6$1...@aioe.org...
> All arrogants can kiss my ass. Is that clear?
:-) Yess, Sir!
> >> We would have to analize other cases where you say
> >> i did that. For example, in the "Property bag/load
> >> resources" thread(s), at the end you understood
> >> the situation,
> > No, already in my second post - and I was sending basically
> > the same recommendations to you with endless endurance
> > until you understood finally what I meant in that second post.
>
> You are not honest.
This is what I wrote in that second post - and IIRC,
this was the solution you preferred in the end of our
discussion in the general-group:
"If you are the provider of the compiled OCX, then you
are free, to include an additional Public Ctl into your
OCX-Project..."
> I don't mind.
Yep, that seems the case.
> >- and it is of course not you who
> > cannot express your problem-domain somewhat better,
> > nahh - all others simply aren't able to follow you.
>
> Is that difficult to say: "i don't understand you?"
<yawn> - No, but there's normally no need to state
something like that explicitely - one has only to look
at the thread-length - if it is long, then it is mostly
very interesting stuff, very complex stuff or there's
a communication-problem between the participants.
In your case I notice a prevalence of the latter - and
no, your problems weren't as complex as you may
think - you simply don't read the replies careful enough.
> I don't have time to loose with this conversation, so i quit.
> Good luck.
Thank you - will see how I can survive without all your
help in these groups. ;-)
> Proverbs 16:18
>
> Pride goeth before destruction, and an haughty spirit
> before a fall.
OMG...
Olaf
Karl E. Peterson
> Kid, i have to learn rules, but you...
> All arrogants can kiss my ass. Is that clear?
LOL! Thanks for the warning. Kid. <ROFLMAO!>
--
.NET: It's About Trust!
http://vfred.mvps.org