Discussion:
Shared library : is it possible to debug ? [VO2.7]
(too old to reply)
Phil Mermod
2006-06-08 13:03:21 UTC
Permalink
Hi VO'ers,

I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....

You can find the sample at : http://www.pkl.ch/download/mylibtest.zip

Thanks for future explanations (if possible regarding the sample)
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Will Chapman
2006-06-08 17:19:37 UTC
Permalink
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
You can find the sample at : http://www.pkl.ch/download/mylibtest.zip
Thanks for future explanations (if possible regarding the sample)
Phil

If I understand what you mean:

1. Create an .exe of myApp with Debug enbaled.
2. Set the application properties of myDLL to
Enable Debug AND Creat VOM file. Finally, Set
the Executable for Debug Session to myApp.exe.
3. Run myDll as an app and the debugger will
open up myApp.exe and myDll.

(If this doesn't work first time, re-index the
project).

Cheers..

Will Chapman
Phil Mermod
2006-06-09 07:47:21 UTC
Permalink
Hi Will,

Thanks for the info. I tried what you wrote but when I start the debugger
from myDll, the application start from the function located in the myDll NOT
from the App:Start of myApp !?!?
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Post by Will Chapman
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
You can find the sample at : http://www.pkl.ch/download/mylibtest.zip
Thanks for future explanations (if possible regarding the sample)
Phil
1. Create an .exe of myApp with Debug enbaled.
2. Set the application properties of myDLL to
Enable Debug AND Creat VOM file. Finally, Set
the Executable for Debug Session to myApp.exe.
3. Run myDll as an app and the debugger will
open up myApp.exe and myDll.
(If this doesn't work first time, re-index the
project).
Cheers..
Will Chapman
Will Chapman
2006-06-09 08:43:46 UTC
Permalink
Post by Phil Mermod
Hi Will,
Thanks for the info. I tried what you wrote but when I start the debugger
from myDll, the application start from the function located in the myDll NOT
from the App:Start of myApp !?!?
Did you try it from MyApp? You may have to fiddle with the
various settings but I'm pretty sure that I have debugged
Dll's like this before using .VOM files. What I have found
is that it doesn't always work first time and you have to
re-index first.

Cheers

Will
Phil Mermod
2006-06-09 12:44:33 UTC
Permalink
Hi Will,

You 're right : it's not working the first time at all. After some reindexes
and touches, it's working now !

Thanks,
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Post by Will Chapman
Post by Phil Mermod
Hi Will,
Thanks for the info. I tried what you wrote but when I start the debugger
from myDll, the application start from the function located in the myDll
NOT from the App:Start of myApp !?!?
Did you try it from MyApp? You may have to fiddle with the
various settings but I'm pretty sure that I have debugged
Dll's like this before using .VOM files. What I have found
is that it doesn't always work first time and you have to
re-index first.
Cheers
Will
GSchaller
2006-06-09 09:37:42 UTC
Permalink
Phil,

It can be done - it's a bit of fiddling but it works. Robert wrote a
sequence of events to follow and it's a shame the instructions didn't
get into the help manual or docs.

Basically all you need to do (in the dll you want to debug) is turn
debugging on and specify the exe which launches the application that
eventually calls into the DLL. You must also make sure the IDE is
pointing to the DLL to debug and VO of course must be active - make sure
the dll does not exist and compile in this state.

Set a break point somewhere in the window, class or function you are
calling as proof of concept. You then start your app in the normal way
and when you get to the break point, the IDE takes focus and you get the
debugger up.

However, I think there is a much easier way.

Temporarily turn your DLL into a library and debug normally <g>.

Geoff
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
You can find the sample at : http://www.pkl.ch/download/mylibtest.zip
Thanks for future explanations (if possible regarding the sample)
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Graham McKechnie
2006-06-09 10:28:00 UTC
Permalink
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more than
one etc.. What a waste of time. So never put code in a DLL unless it's fully
debugged. All very practical....

Just another example of how bad VO really is.

Graham
Phil,
It can be done - it's a bit of fiddling but it works. Robert wrote a
sequence of events to follow and it's a shame the instructions didn't get
into the help manual or docs.
Basically all you need to do (in the dll you want to debug) is turn
debugging on and specify the exe which launches the application that
eventually calls into the DLL. You must also make sure the IDE is pointing
to the DLL to debug and VO of course must be active - make sure the dll
does not exist and compile in this state.
Set a break point somewhere in the window, class or function you are
calling as proof of concept. You then start your app in the normal way and
when you get to the break point, the IDE takes focus and you get the
debugger up.
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
Geoff
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
You can find the sample at : http://www.pkl.ch/download/mylibtest.zip
Thanks for future explanations (if possible regarding the sample)
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
GSchaller
2006-06-09 11:14:32 UTC
Permalink
<g>
So never put code in a DLL unless it's fully debugged.
This is probably the best advice.

And then I don't use the debugger like that ever. Never have and never
will, for VO. But VS, now there's a different tune...

Geoff
Will Chapman
2006-06-09 12:45:01 UTC
Permalink
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more than
one etc.. What a waste of time. So never put code in a DLL unless it's fully
debugged. All very practical....
Just another example of how bad VO really is.
Forgive me Grum but I don't see why that is an example
of how bad VO is. The DLL debug procedure works, I've used
it many times...sometimes you know it isn't appropriate to put
everything in a library, I've often distributed .DLL's
as part of a tool kit.

CHeers

Will Chapman
Graham McKechnie
2006-06-09 19:15:39 UTC
Permalink
Will,

I'm not saying it can't be done in VO, I've also done it in the past.
However now that you're coding regularly in C#, do the same thing there and
see how much easier it is to do.

Graham
Post by Will Chapman
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more
than one etc.. What a waste of time. So never put code in a DLL unless
it's fully debugged. All very practical....
Just another example of how bad VO really is.
Forgive me Grum but I don't see why that is an example
of how bad VO is. The DLL debug procedure works, I've used
it many times...sometimes you know it isn't appropriate to put
everything in a library, I've often distributed .DLL's
as part of a tool kit.
CHeers
Will Chapman
Will Chapman
2006-06-09 19:55:30 UTC
Permalink
Post by Graham McKechnie
Will,
I'm not saying it can't be done in VO, I've also done it in the past.
Then why say that VO is bad...it does the job.
Post by Graham McKechnie
However now that you're coding regularly in C#, do the same thing there and
see how much easier it is to do.
Well, I'm coding everday in C# and it is good (its more modern) but
I am no where up to the`speed that I am with VO. Some things that I use
a lot, notably arrays, are much easier to handle in VO. So whilst I like
both languages I just don't classify either one of them as 'bad'.

At this stage in my move to .NET I have an open mind but if Vulcan turns
out as I expect, I will use it for the simple reason that I am unlikely
(at my age!) to ever become as fluent in C# as I am VO.

More
to the point, I just don't see why you hate the language so much that
you keep popping up here to knock it. I dislike Visual Basic I don't
spend my time knocking the language on VB forums.


CHeers

Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more
than one etc.. What a waste of time. So never put code in a DLL unless
it's fully debugged. All very practical....
Just another example of how bad VO really is.
Forgive me Grum but I don't see why that is an example
of how bad VO is. The DLL debug procedure works, I've used
it many times...sometimes you know it isn't appropriate to put
everything in a library, I've often distributed .DLL's
as part of a tool kit.
CHeers
Will Chapman
Graham McKechnie
2006-06-10 02:27:58 UTC
Permalink
Will,
Post by Will Chapman
Then why say that VO is bad...it does the job.
Because of the non intuitive way you have to go about it. That is not
knocking the language itself, its the bloody implementation I've never liked
and I suppose we have Sabo to blame for that, but hell it could have been
changed by the new owner. Have a go at doing the same thing in C# and just
see how easy it is. Phil wouldn't be having the hard time that he is using
VO if he was using C#. He probably wouldn't have even asked the question!!
Post by Will Chapman
Some things that I use a lot, notably arrays, are much easier to handle in
VO.
Well I can't say that I agree with your there either. What is it about VO
arrays that you like so much? Or the other way around what do you find more
difficult about arrays in C#?
Post by Will Chapman
....I will use it for the simple reason that I am unlikely (at my age!) to
ever become as fluent in C# as I am VO.
Why not? If one old bloke can make the move, I can't see why another can't.
Post by Will Chapman
More to the point....
I've told you before, I enjoy the entertainment here. There is no other
language forum that I know of, that has the goings on of this one. I don't
watch TV soaps - don't have to, when you've got this place.

Graham
Post by Will Chapman
Post by Graham McKechnie
Will,
I'm not saying it can't be done in VO, I've also done it in the past.
Then why say that VO is bad...it does the job.
Post by Graham McKechnie
However now that you're coding regularly in C#, do the same thing there
and see how much easier it is to do.
Well, I'm coding everday in C# and it is good (its more modern) but
I am no where up to the`speed that I am with VO. Some things that I use a
lot, notably arrays, are much easier to handle in VO. So whilst I like
both languages I just don't classify either one of them as 'bad'.
At this stage in my move to .NET I have an open mind but if Vulcan turns
out as I expect, I will use it for the simple reason that I am unlikely
(at my age!) to ever become as fluent in C# as I am VO.
More
to the point, I just don't see why you hate the language so much that you
keep popping up here to knock it. I dislike Visual Basic I don't
spend my time knocking the language on VB forums.
CHeers
Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more
than one etc.. What a waste of time. So never put code in a DLL unless
it's fully debugged. All very practical....
Just another example of how bad VO really is.
Forgive me Grum but I don't see why that is an example
of how bad VO is. The DLL debug procedure works, I've used
it many times...sometimes you know it isn't appropriate to put
everything in a library, I've often distributed .DLL's
as part of a tool kit.
CHeers
Will Chapman
Will Chapman
2006-06-10 09:56:41 UTC
Permalink
Post by Graham McKechnie
Post by Will Chapman
Some things that I use a lot, notably arrays, are much easier to handle in
VO.
Well I can't say that I agree with your there either. What is it about VO
arrays that you like so much? Or the other way around what do you find more
difficult about arrays in C#?
I just find VO array handling a lot, lot more intuitive and concise to
code. Juzst look at this single line which is PART of a class and method
that I had to write to replace a couple of lines using AADD() and Asort()>

(mapA.MapName.CompareTo(((MapArray)obj2).MapName)

You call that intuitive?!
Post by Graham McKechnie
Post by Will Chapman
....I will use it for the simple reason that I am unlikely (at my age!) to
ever become as fluent in C# as I am VO.
Why not? If one old bloke can make the move, I can't see why another can't.
I suspect I'm several years older than you (69) and I have plans other
than learning new languages...;>)
Post by Graham McKechnie
Post by Will Chapman
More to the point....
I've told you before, I enjoy the entertainment here. There is no other
language forum that I know of, that has the goings on of this one.
Thats true....but its also true that you are one of the disruptive
forces that fuel those 'goings on' and so I can only conclude that
there is more behind your posts than meets the eye. And anyway, what
sort of person kicks something that they belive is already down?

Personally, I have better things to do with my time.

Cheers


Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Will,
I'm not saying it can't be done in VO, I've also done it in the past.
Then why say that VO is bad...it does the job.
Post by Graham McKechnie
However now that you're coding regularly in C#, do the same thing there
and see how much easier it is to do.
Well, I'm coding everday in C# and it is good (its more modern) but
I am no where up to the`speed that I am with VO. Some things that I use a
lot, notably arrays, are much easier to handle in VO. So whilst I like
both languages I just don't classify either one of them as 'bad'.
At this stage in my move to .NET I have an open mind but if Vulcan turns
out as I expect, I will use it for the simple reason that I am unlikely
(at my age!) to ever become as fluent in C# as I am VO.
More
to the point, I just don't see why you hate the language so much that you
keep popping up here to knock it. I dislike Visual Basic I don't
spend my time knocking the language on VB forums.
CHeers
Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more
than one etc.. What a waste of time. So never put code in a DLL unless
it's fully debugged. All very practical....
Just another example of how bad VO really is.
Forgive me Grum but I don't see why that is an example
of how bad VO is. The DLL debug procedure works, I've used
it many times...sometimes you know it isn't appropriate to put
everything in a library, I've often distributed .DLL's
as part of a tool kit.
CHeers
Will Chapman
Ginny Caughey
2006-06-10 10:09:04 UTC
Permalink
Will,

Why don't you use ArrayList or List<T> for your collections? There's an Add
method that does what you want.
--
Ginny
Post by Will Chapman
Post by Graham McKechnie
Post by Will Chapman
Some things that I use a lot, notably arrays, are much easier to handle
in VO.
Well I can't say that I agree with your there either. What is it about VO
arrays that you like so much? Or the other way around what do you find
more difficult about arrays in C#?
I just find VO array handling a lot, lot more intuitive and concise to
code. Juzst look at this single line which is PART of a class and method
that I had to write to replace a couple of lines using AADD() and Asort()>
(mapA.MapName.CompareTo(((MapArray)obj2).MapName)
You call that intuitive?!
Post by Graham McKechnie
Post by Will Chapman
....I will use it for the simple reason that I am unlikely (at my age!)
to ever become as fluent in C# as I am VO.
Why not? If one old bloke can make the move, I can't see why another can't.
I suspect I'm several years older than you (69) and I have plans other
than learning new languages...;>)
Post by Graham McKechnie
Post by Will Chapman
More to the point....
I've told you before, I enjoy the entertainment here. There is no other
language forum that I know of, that has the goings on of this one.
Thats true....but its also true that you are one of the disruptive forces
that fuel those 'goings on' and so I can only conclude that
there is more behind your posts than meets the eye. And anyway, what
sort of person kicks something that they belive is already down?
Personally, I have better things to do with my time.
Cheers
Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Will,
I'm not saying it can't be done in VO, I've also done it in the past.
Then why say that VO is bad...it does the job.
Post by Graham McKechnie
However now that you're coding regularly in C#, do the same thing there
and see how much easier it is to do.
Well, I'm coding everday in C# and it is good (its more modern) but
I am no where up to the`speed that I am with VO. Some things that I use
a lot, notably arrays, are much easier to handle in VO. So whilst I like
both languages I just don't classify either one of them as 'bad'.
At this stage in my move to .NET I have an open mind but if Vulcan turns
out as I expect, I will use it for the simple reason that I am unlikely
(at my age!) to ever become as fluent in C# as I am VO.
More
to the point, I just don't see why you hate the language so much that
you keep popping up here to knock it. I dislike Visual Basic I don't
spend my time knocking the language on VB forums.
CHeers
Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more
than one etc.. What a waste of time. So never put code in a DLL
unless it's fully debugged. All very practical....
Just another example of how bad VO really is.
Forgive me Grum but I don't see why that is an example
of how bad VO is. The DLL debug procedure works, I've used
it many times...sometimes you know it isn't appropriate to put
everything in a library, I've often distributed .DLL's
as part of a tool kit.
CHeers
Will Chapman
Will Chapman
2006-06-10 10:19:05 UTC
Permalink
Post by Ginny Caughey
Will,
Why don't you use ArrayList or List<T> for your collections? There's an Add
method that does what you want.
Ginny

I am using ArrayList.Add(). The example I gave is part of a class
inherited from ArrayList but because I need to sort on more than one
element I've found it necessary to write sort methods. It would become
clearer if I posted the entire class/method but I thought that would
take the thread even further off-topic ;>)!

Cheers...

Will
Graham McKechnie
2006-06-10 12:19:45 UTC
Permalink
Will,
Post by Will Chapman
(mapA.MapName.CompareTo(((MapArray)obj2).MapName)
You call that intuitive?!
No, I don't.

But you don't have to write stuff that way. Don't think VO, think C#. I know
that can be difficult after years of VO, that's why my advice is delete VO
from your disk or at least put it in another room and give yourself a
chance.

You may find something like the following easier to follow. Assume the class
Players has a member ArrayList playerList and the following methods. You
could easily have classes Map and Maps for your GPS stuff.

public void Sort(IComparer myComparer)
{
this.playerList.Sort( myComparer );
}

public static IComparer SortByName
{
get{ return (IComparer) new SortByNameClass(); }
}

private class SortByNameClass : IComparer
{
public SortByNameClass(){}

int IComparer.Compare( object object1, object object2 )
{
PlayerBL player1 = (PlayerBL)object1;
PlayerBL player2 = (PlayerBL)object2;

return String.Compare( player1.Name, player2.Name);
}
}

The implementation might look a little complex, but I doubt anyone would
think the following lines are.

players.Sort(Players.SortByName);

or something similar, but just as intuitive

players.Sort(Players.SortByHandicap);

The playerBL class has many fields, the players class (the collection) can
then add a heap of functionality to the class.

I've read some pretty amazing VO ASorts over the years,`which could hardly
be called intuitive. They give you a headache just looking at them, so it
can cut both ways.
Post by Will Chapman
Thats true....but its also true that you are one of the disruptive forces
that fuel those 'goings on' and so I can only conclude that
there is more behind your posts than meets the eye. And anyway, what
sort of person kicks something that they belive is already down?
You have a right to your opinion, but your conclusions are way off. This
forum doesn't need any fueling, its always at just below flash point without
any assistance from me. There is nothing sinister in my posts, I don't have
any agenda here as you and others have suggested in the past. I just
occasionally comment re some of the dumb comments made here such as in this
thread.
Post by Will Chapman
And anyway, what sort of person kicks something that they belive is already
down?
You mean like your cricket team. Roll on summer<g>

Graham
Post by Will Chapman
Post by Graham McKechnie
Post by Will Chapman
Some things that I use a lot, notably arrays, are much easier to handle
in VO.
Well I can't say that I agree with your there either. What is it about VO
arrays that you like so much? Or the other way around what do you find
more difficult about arrays in C#?
I just find VO array handling a lot, lot more intuitive and concise to
code. Juzst look at this single line which is PART of a class and method
that I had to write to replace a couple of lines using AADD() and Asort()>
(mapA.MapName.CompareTo(((MapArray)obj2).MapName)
You call that intuitive?!
Post by Graham McKechnie
Post by Will Chapman
....I will use it for the simple reason that I am unlikely (at my age!)
to ever become as fluent in C# as I am VO.
Why not? If one old bloke can make the move, I can't see why another can't.
I suspect I'm several years older than you (69) and I have plans other
than learning new languages...;>)
Post by Graham McKechnie
Post by Will Chapman
More to the point....
I've told you before, I enjoy the entertainment here. There is no other
language forum that I know of, that has the goings on of this one.
Thats true....but its also true that you are one of the disruptive forces
that fuel those 'goings on' and so I can only conclude that
there is more behind your posts than meets the eye. And anyway, what
sort of person kicks something that they belive is already down?
Personally, I have better things to do with my time.
Cheers
Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Will,
I'm not saying it can't be done in VO, I've also done it in the past.
Then why say that VO is bad...it does the job.
Post by Graham McKechnie
However now that you're coding regularly in C#, do the same thing there
and see how much easier it is to do.
Well, I'm coding everday in C# and it is good (its more modern) but
I am no where up to the`speed that I am with VO. Some things that I use
a lot, notably arrays, are much easier to handle in VO. So whilst I like
both languages I just don't classify either one of them as 'bad'.
At this stage in my move to .NET I have an open mind but if Vulcan turns
out as I expect, I will use it for the simple reason that I am unlikely
(at my age!) to ever become as fluent in C# as I am VO.
More
to the point, I just don't see why you hate the language so much that
you keep popping up here to knock it. I dislike Visual Basic I don't
spend my time knocking the language on VB forums.
CHeers
Will Chapman
Post by Graham McKechnie
Graham
Post by Will Chapman
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more
than one etc.. What a waste of time. So never put code in a DLL
unless it's fully debugged. All very practical....
Just another example of how bad VO really is.
Forgive me Grum but I don't see why that is an example
of how bad VO is. The DLL debug procedure works, I've used
it many times...sometimes you know it isn't appropriate to put
everything in a library, I've often distributed .DLL's
as part of a tool kit.
CHeers
Will Chapman
Will Chapman
2006-06-10 20:09:50 UTC
Permalink
Post by Graham McKechnie
Will,
Post by Will Chapman
(mapA.MapName.CompareTo(((MapArray)obj2).MapName)
You call that intuitive?!
No, I don't.
But you don't have to write stuff that way.
Maybe so but Im' learning by taking exemplar stuff I
find on various 'official' and/or expert websites.
Post by Graham McKechnie
You may find something like the following easier to follow. Assume the class
Players has a member ArrayList playerList and the following methods. You
could easily have classes Map and Maps for your GPS stuff.
public void Sort(IComparer myComparer)
{
this.playerList.Sort( myComparer );
}
This is exactly the sort of syntax I'm using; but I think
its less intuitive than VO.
Post by Graham McKechnie
Post by Will Chapman
And anyway, what sort of person kicks something that they belive is already
down?
You mean like your cricket team. Roll on summer<g>
Well, we need to win the World Cup (soccer) first then
we'll see whether we can give you a thumping at cricket
again as we did last summer.

Cheers...

Will
Phil Mermod
2006-06-09 12:53:56 UTC
Permalink
Hi Graham,

Unfortunately, I cannot put all the code in one lib. Our customers are using
the same structure of DLL (same class, methods, assign, access names) but
with different contents in every method so they have their own DLL for the
specific business processes. This is particulary very useful and flexible
for us. Even we can distribute only one DLL to one customer after fixing
problems or adding features.

Of course we have some common libraries shared by the main application, and
specific DLL's.
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more than
one etc.. What a waste of time. So never put code in a DLL unless it's
fully debugged. All very practical....
Just another example of how bad VO really is.
Graham
Phil,
It can be done - it's a bit of fiddling but it works. Robert wrote a
sequence of events to follow and it's a shame the instructions didn't get
into the help manual or docs.
Basically all you need to do (in the dll you want to debug) is turn
debugging on and specify the exe which launches the application that
eventually calls into the DLL. You must also make sure the IDE is
pointing to the DLL to debug and VO of course must be active - make sure
the dll does not exist and compile in this state.
Set a break point somewhere in the window, class or function you are
calling as proof of concept. You then start your app in the normal way
and when you get to the break point, the IDE takes focus and you get the
debugger up.
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
Geoff
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
You can find the sample at : http://www.pkl.ch/download/mylibtest.zip
Thanks for future explanations (if possible regarding the sample)
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Graham McKechnie
2006-06-09 19:17:12 UTC
Permalink
Phil,
Post by Phil Mermod
Unfortunately, I cannot put all the code in one lib.
I wasn't suggesting that.

Graham
Post by Phil Mermod
Hi Graham,
Unfortunately, I cannot put all the code in one lib. Our customers are
using the same structure of DLL (same class, methods, assign, access
names) but with different contents in every method so they have their own
DLL for the specific business processes. This is particulary very useful
and flexible for us. Even we can distribute only one DLL to one customer
after fixing problems or adding features.
Of course we have some common libraries shared by the main application,
and specific DLL's.
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Post by Graham McKechnie
Geoff,
.>Temporarily turn your DLL into a library and debug normally <g>.
Sure very easy to do when your lib is huge. Bad luck if you have more
than one etc.. What a waste of time. So never put code in a DLL unless
it's fully debugged. All very practical....
Just another example of how bad VO really is.
Graham
Phil,
It can be done - it's a bit of fiddling but it works. Robert wrote a
sequence of events to follow and it's a shame the instructions didn't
get into the help manual or docs.
Basically all you need to do (in the dll you want to debug) is turn
debugging on and specify the exe which launches the application that
eventually calls into the DLL. You must also make sure the IDE is
pointing to the DLL to debug and VO of course must be active - make sure
the dll does not exist and compile in this state.
Set a break point somewhere in the window, class or function you are
calling as proof of concept. You then start your app in the normal way
and when you get to the break point, the IDE takes focus and you get the
debugger up.
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
Geoff
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
You can find the sample at : http://www.pkl.ch/download/mylibtest.zip
Thanks for future explanations (if possible regarding the sample)
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Phil Mermod
2006-06-09 12:46:41 UTC
Permalink
Hi Geoff,

Thanks for your advices : it's really tricky to make it right and running...
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
Post by GSchaller
Phil,
It can be done - it's a bit of fiddling but it works. Robert wrote a
sequence of events to follow and it's a shame the instructions didn't get
into the help manual or docs.
Basically all you need to do (in the dll you want to debug) is turn
debugging on and specify the exe which launches the application that
eventually calls into the DLL. You must also make sure the IDE is pointing
to the DLL to debug and VO of course must be active - make sure the dll
does not exist and compile in this state.
Set a break point somewhere in the window, class or function you are
calling as proof of concept. You then start your app in the normal way and
when you get to the break point, the IDE takes focus and you get the
debugger up.
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
Geoff
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
You can find the sample at : http://www.pkl.ch/download/mylibtest.zip
Thanks for future explanations (if possible regarding the sample)
--
Phil Mermod
PKL - R&D - CTO
Pension Funds Solutions
http://www.pkl.ch
gstark
2006-06-11 00:23:12 UTC
Permalink
Post by GSchaller
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
As long as the source code is physically linked into the application - regardless
of whether it's a library or a dll - it can be called by the debugger.

No need to delete any flies; just link the physical source to the app, set
debugging on for the relevant modules, set a breakpoint or three, and go.

Of course, there may be interdependancy issues that also need to be addressed.

Another soultion is to simply pull the relevant code out of the DLL application
and stuff it back into the primary application for the purposes of debugging.

Again, there may be dependancy issues to address, but that raises the question of
why is somebody debugging a DLL anyway? Shouldn't the code in one's DLLs be solid
and tried, tested and already proven to be solid ? :)

And of course a final solution is that you forget about using a realtime debugger,
and pass the snippets of data that you want to see to a separate application
running on the same box, or running on another box usint winsock.


--
g.
Gary Stark
***@RedbacksWeb.com
http:\\www.RedbacksWeb.com
GSchaller
2006-06-11 02:16:48 UTC
Permalink
Gary,

At Duncan's insistence (especially over the HN stuff <g>) we took our
two major apps we had that deployed 16 separate dll's and turned them
into one giant exe. Everything became just another library. This has
pluses and minuses and I leave the readers out there to choose:

Positives:
==========

1. Debugging across the entire app is automatic and complete.
2. In the multi-developer environment, it is much easier to manage.
3. Source control becomes much more, well... controllable.
4. Absolutely no more dll hell and version problems.
5. In the IDE, you can right click any entity and reach the source code.
This is not possible in a DLL driven environment. You can only ever
reach prototypes.
6. You can "lose" the VOPP prototype management concept, which is a plus
because of VOPP's added instability with the latest VO builds.


Negatives:
==========

1. The exe became some 30MB, necessitating runtime compression for
delivery (it shrunk back to 4MB so this is now ok).
2. If multiple apps used what were once common DLLs, there is additional
management required to keep them in sync. A headache sometimes.
3. You always need to distribute the full 4MB (no little DLL patches).
4. VO is much more unstable managing such a large repo and recompile.
The need for reindexing is much more frequent and Adam needs wider
limits.
5. You have lost all the runtime benefits of DLL's.
6. You cannot hope to incorporate tools like the COMSDK and expect VO to
compile cleanly without a lot of effort and constant reindexing. This is
because the IDE cannot handle the large number of dependent entities.

Cheers,

Geoff

PS
Post by gstark
Another soultion is to simply pull the relevant code out of the DLL
application and stuff it back into the primary application for the
purposes of debugging.
I perhaps like this approach also but it can be difficult, as you next
commented, on account of dependencies. It also takes a lot of effort.
But you could duplicate the class and change its name thus preserving
existing dependencies.
Post by gstark
Post by GSchaller
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
As long as the source code is physically linked into the application - regardless
of whether it's a library or a dll - it can be called by the debugger.
No need to delete any flies; just link the physical source to the app, set
debugging on for the relevant modules, set a breakpoint or three, and go.
Of course, there may be interdependancy issues that also need to be addressed.
Another soultion is to simply pull the relevant code out of the DLL application
and stuff it back into the primary application for the purposes of debugging.
Again, there may be dependancy issues to address, but that raises the question of
why is somebody debugging a DLL anyway? Shouldn't the code in one's DLLs be solid
and tried, tested and already proven to be solid ? :)
And of course a final solution is that you forget about using a realtime debugger,
and pass the snippets of data that you want to see to a separate application
running on the same box, or running on another box usint winsock.
--
g.
Gary Stark
http:\\www.RedbacksWeb.com
Graham McKechnie
2006-06-11 03:48:54 UTC
Permalink
Geoff,

And you guys still put up with this. I saw this years ago and couldn't
believe it then. I just can't believe you want to keep working this way.
Does anyone every get to write any code or are you forever reindexing all
day long. To think that Norwich paid us up top money to develop that way,
what a waste!!

Did some one say here that I shouldn't knock VO???

So much easier doing it the VS way, you never have to give it a thought
whether you are using a dll or not.

Graham
Gary,
At Duncan's insistence (especially over the HN stuff <g>) we took our two
major apps we had that deployed 16 separate dll's and turned them into one
giant exe. Everything became just another library. This has pluses and
==========
1. Debugging across the entire app is automatic and complete.
2. In the multi-developer environment, it is much easier to manage.
3. Source control becomes much more, well... controllable.
4. Absolutely no more dll hell and version problems.
5. In the IDE, you can right click any entity and reach the source code.
This is not possible in a DLL driven environment. You can only ever reach
prototypes.
6. You can "lose" the VOPP prototype management concept, which is a plus
because of VOPP's added instability with the latest VO builds.
==========
1. The exe became some 30MB, necessitating runtime compression for
delivery (it shrunk back to 4MB so this is now ok).
2. If multiple apps used what were once common DLLs, there is additional
management required to keep them in sync. A headache sometimes.
3. You always need to distribute the full 4MB (no little DLL patches).
4. VO is much more unstable managing such a large repo and recompile. The
need for reindexing is much more frequent and Adam needs wider limits.
5. You have lost all the runtime benefits of DLL's.
6. You cannot hope to incorporate tools like the COMSDK and expect VO to
compile cleanly without a lot of effort and constant reindexing. This is
because the IDE cannot handle the large number of dependent entities.
Cheers,
Geoff
PS
Post by gstark
Another soultion is to simply pull the relevant code out of the DLL
application and stuff it back into the primary application for the
purposes of debugging.
I perhaps like this approach also but it can be difficult, as you next
commented, on account of dependencies. It also takes a lot of effort. But
you could duplicate the class and change its name thus preserving existing
dependencies.
Post by gstark
Post by GSchaller
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
As long as the source code is physically linked into the application - regardless
of whether it's a library or a dll - it can be called by the debugger.
No need to delete any flies; just link the physical source to the app, set
debugging on for the relevant modules, set a breakpoint or three, and go.
Of course, there may be interdependancy issues that also need to be addressed.
Another soultion is to simply pull the relevant code out of the DLL application
and stuff it back into the primary application for the purposes of debugging.
Again, there may be dependancy issues to address, but that raises the question of
why is somebody debugging a DLL anyway? Shouldn't the code in one's DLLs be solid
and tried, tested and already proven to be solid ? :)
And of course a final solution is that you forget about using a realtime debugger,
and pass the snippets of data that you want to see to a separate application
running on the same box, or running on another box usint winsock.
--
g.
Gary Stark
http:\\www.RedbacksWeb.com
GSchaller
2006-06-11 05:17:57 UTC
Permalink
Graham.

Don't let your pathological hate of all things Brian get in the way of
balanced judgement <g>. Whilst I too think Brian has made a complete
mess of VO since taking it away from CA and squandered the opportunity,
VO still retains some important productivity benefits over VS.

No matter what you say and no matter how many people I see with VS, the
productivity benefit, line for line, just doesn't match up to VO's IDE.
So many things are just so much simpler in VO. And faster! By a long
margin. Also, the current build of VS 2005 is pitifully slow (compared
to VS 2003) and very frustrating if you want to move properties windows
to anywhere other than their docked default. If they don't fix these
simple performance features, people will leave the environment for
alternates.

I think your array example is a simple case in point. Whilst I am quite
able and happy to use C# the way you show, it is but a direct example of
where the extra class and method handling just isn't needed in VO. One
line of code becomes many and an overhead it necessary.

VS and C# is NOT easier than VO in almost anything. That is not to say
that there also aren't important pluses in moving to VS but language
complexity and ease of us can never be cited as one of them.

You will never win that argument in this forum <g>.

Geoff
Post by Graham McKechnie
Geoff,
And you guys still put up with this. I saw this years ago and couldn't
believe it then. I just can't believe you want to keep working this way.
Does anyone every get to write any code or are you forever reindexing all
day long. To think that Norwich paid us up top money to develop that way,
what a waste!!
Did some one say here that I shouldn't knock VO???
So much easier doing it the VS way, you never have to give it a thought
whether you are using a dll or not.
Graham
Gary,
At Duncan's insistence (especially over the HN stuff <g>) we took our two
major apps we had that deployed 16 separate dll's and turned them into one
giant exe. Everything became just another library. This has pluses and
==========
1. Debugging across the entire app is automatic and complete.
2. In the multi-developer environment, it is much easier to manage.
3. Source control becomes much more, well... controllable.
4. Absolutely no more dll hell and version problems.
5. In the IDE, you can right click any entity and reach the source code.
This is not possible in a DLL driven environment. You can only ever reach
prototypes.
6. You can "lose" the VOPP prototype management concept, which is a plus
because of VOPP's added instability with the latest VO builds.
==========
1. The exe became some 30MB, necessitating runtime compression for
delivery (it shrunk back to 4MB so this is now ok).
2. If multiple apps used what were once common DLLs, there is additional
management required to keep them in sync. A headache sometimes.
3. You always need to distribute the full 4MB (no little DLL patches).
4. VO is much more unstable managing such a large repo and recompile. The
need for reindexing is much more frequent and Adam needs wider limits.
5. You have lost all the runtime benefits of DLL's.
6. You cannot hope to incorporate tools like the COMSDK and expect VO to
compile cleanly without a lot of effort and constant reindexing. This is
because the IDE cannot handle the large number of dependent entities.
Cheers,
Geoff
PS
Post by gstark
Another soultion is to simply pull the relevant code out of the DLL
application and stuff it back into the primary application for the
purposes of debugging.
I perhaps like this approach also but it can be difficult, as you next
commented, on account of dependencies. It also takes a lot of effort. But
you could duplicate the class and change its name thus preserving existing
dependencies.
Post by gstark
Post by GSchaller
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
As long as the source code is physically linked into the application - regardless
of whether it's a library or a dll - it can be called by the debugger.
No need to delete any flies; just link the physical source to the app, set
debugging on for the relevant modules, set a breakpoint or three, and go.
Of course, there may be interdependancy issues that also need to be addressed.
Another soultion is to simply pull the relevant code out of the DLL application
and stuff it back into the primary application for the purposes of debugging.
Again, there may be dependancy issues to address, but that raises the question of
why is somebody debugging a DLL anyway? Shouldn't the code in one's DLLs be solid
and tried, tested and already proven to be solid ? :)
And of course a final solution is that you forget about using a realtime debugger,
and pass the snippets of data that you want to see to a separate application
running on the same box, or running on another box usint winsock.
--
g.
Gary Stark
http:\\www.RedbacksWeb.com
Graham McKechnie
2006-06-11 06:22:42 UTC
Permalink
Geoff,
Post by GSchaller
Don't let your pathological hate of all things Brian get in the way of
balanced judgement <g>.
Yeh, I wake up every morning and the dog reminds me.<g> . Somehow I think I
have better things to think about.
Post by GSchaller
Post by GSchaller
No matter what you say and no matter how many people I see with VS, the
productivity benefit, line for line, just doesn't match up to VO's IDE.
That is contradictory to what you just stated about using dll's with VO in
your previous post - the one I was replying to. Nothing like changing tack
to suit your argument. Is the use of dll's in VO in a big app a PITA or not?
I thought you were agreeing, or are you about to retract your list.
Post by GSchaller
Post by GSchaller
And faster! By a long margin.
Can't imagine how if you spend your whole day reindexing the repo. Jezz do I
remember doing that... Hey why is it always Dunc's code we are talking
about.<VBG>
Post by GSchaller
Post by GSchaller
Also, the current build of VS 2005 is pitifully slow (compared to VS 2003)
Yes it is slower, but it provides a lot more features than 2003. I swap
between 2003 and 2005 many times each day and I can't say I really notice a
great difference. I thought you had a fast machine!!!! Maybe time to buy
something quicker eh.. We could start the Centrino, P4 discussion again -
haven't done that here for a while. Dual core these days, I suppose you
don't like them either..
Post by GSchaller
very frustrating if you want to move properties windows to anywhere other
than their docked default.
You've got a thing about this docking stuff, haven't you? I really don't
understand, I spend most of the day with the editor taking up all the screen
while I'm writing code. I hardly ever go near a property window unless I'm
designing or changing a window. Why the big deal about the requirement for
a property window or it getting in the way. Just close it when you don't
need it, it will come back with another click!!!
Post by GSchaller
but a direct example of where the extra class and method handling just
isn't needed in VO. One line of code becomes many and an overhead it
necessary.
Well you know I'm not going to agree with you there. I'd rather spend time
in the design phase, get the class design right. If it requires a couple of
more classes to do it right, then I'm going to do that every time - Doesn't
matter if it's VO or C#, just that it is easier in C#, because there are
more language features to choose from. I'd probably get the extra class(s)
done while you were waiting for your reindex to finish.
Post by GSchaller
You will never win that argument in this forum <g>.
Guess what, I'm not trying. I've already convinced the only guy that matters
here.

Graham
Post by GSchaller
Graham.
Don't let your pathological hate of all things Brian get in the way of
balanced judgement <g>. Whilst I too think Brian has made a complete mess
of VO since taking it away from CA and squandered the opportunity, VO
still retains some important productivity benefits over VS.
No matter what you say and no matter how many people I see with VS, the
productivity benefit, line for line, just doesn't match up to VO's IDE. So
many things are just so much simpler in VO. And faster! By a long margin.
Also, the current build of VS 2005 is pitifully slow (compared to VS 2003)
and very frustrating if you want to move properties windows to anywhere
other than their docked default. If they don't fix these simple
performance features, people will leave the environment for alternates.
I think your array example is a simple case in point. Whilst I am quite
able and happy to use C# the way you show, it is but a direct example of
where the extra class and method handling just isn't needed in VO. One
line of code becomes many and an overhead it necessary.
VS and C# is NOT easier than VO in almost anything. That is not to say
that there also aren't important pluses in moving to VS but language
complexity and ease of us can never be cited as one of them.
You will never win that argument in this forum <g>.
Geoff
Post by GSchaller
Geoff,
And you guys still put up with this. I saw this years ago and couldn't
believe it then. I just can't believe you want to keep working this way.
Does anyone every get to write any code or are you forever reindexing all
day long. To think that Norwich paid us up top money to develop that way,
what a waste!!
Did some one say here that I shouldn't knock VO???
So much easier doing it the VS way, you never have to give it a thought
whether you are using a dll or not.
Graham
Gary,
At Duncan's insistence (especially over the HN stuff <g>) we took our two
major apps we had that deployed 16 separate dll's and turned them into one
giant exe. Everything became just another library. This has pluses and
==========
1. Debugging across the entire app is automatic and complete.
2. In the multi-developer environment, it is much easier to manage.
3. Source control becomes much more, well... controllable.
4. Absolutely no more dll hell and version problems.
5. In the IDE, you can right click any entity and reach the source code.
This is not possible in a DLL driven environment. You can only ever reach
prototypes.
6. You can "lose" the VOPP prototype management concept, which is a plus
because of VOPP's added instability with the latest VO builds.
==========
1. The exe became some 30MB, necessitating runtime compression for
delivery (it shrunk back to 4MB so this is now ok).
2. If multiple apps used what were once common DLLs, there is additional
management required to keep them in sync. A headache sometimes.
3. You always need to distribute the full 4MB (no little DLL patches).
4. VO is much more unstable managing such a large repo and recompile. The
need for reindexing is much more frequent and Adam needs wider limits.
5. You have lost all the runtime benefits of DLL's.
6. You cannot hope to incorporate tools like the COMSDK and expect VO to
compile cleanly without a lot of effort and constant reindexing. This is
because the IDE cannot handle the large number of dependent entities.
Cheers,
Geoff
PS
Post by gstark
Another soultion is to simply pull the relevant code out of the DLL
application and stuff it back into the primary application for the
purposes of debugging.
I perhaps like this approach also but it can be difficult, as you next
commented, on account of dependencies. It also takes a lot of effort. But
you could duplicate the class and change its name thus preserving existing
dependencies.
Post by gstark
Post by GSchaller
However, I think there is a much easier way.
Temporarily turn your DLL into a library and debug normally <g>.
As long as the source code is physically linked into the application - regardless
of whether it's a library or a dll - it can be called by the debugger.
No need to delete any flies; just link the physical source to the app, set
debugging on for the relevant modules, set a breakpoint or three, and go.
Of course, there may be interdependancy issues that also need to be addressed.
Another soultion is to simply pull the relevant code out of the DLL application
and stuff it back into the primary application for the purposes of debugging.
Again, there may be dependancy issues to address, but that raises the question of
why is somebody debugging a DLL anyway? Shouldn't the code in one's
DLLs
be solid
and tried, tested and already proven to be solid ? :)
And of course a final solution is that you forget about using a
realtime
debugger,
and pass the snippets of data that you want to see to a separate application
running on the same box, or running on another box usint winsock.
--
g.
Gary Stark
http:\\www.RedbacksWeb.com
GSchaller
2006-06-11 07:34:51 UTC
Permalink
Graham,
Post by Graham McKechnie
Yeh, I wake up every morning and the dog reminds me.<g> .
Don't kick it then... <g>
Post by Graham McKechnie
That is contradictory to what you just stated about using dll's with VO in
your previous post - the one I was replying to. Nothing like changing tack
No its not, in fact the same difficulties arise with DLL management for
VS just as much as VO. The only point I will concede is error handling
into the debugger is a generation better than VO but most other aspects
suffer the same issues as all IDEs. As I said, my solution in VO was to
make one huge app and from what I see with VS, that tends to be the way
I see most people coding.
Post by Graham McKechnie
Can't imagine how if you spend your whole day reindexing the repo.
Well let's not overdo it. The reindex takes about 4 seconds. A full
recompile about 3 minutes (but I only need to do this once every couple
of days). I might add here that a VS full recompile takes a helluva lot
longer than a VO compile for the same amount of code - even VS 2003! In
fact, sometimes the IDE goes into go-slow and starts doing a VO on my.
Post by Graham McKechnie
great difference. I thought you had a fast machine!!!! Maybe time to buy
I do - this is what disappointed me. Mostly its seems to be like VO:
setting up buffers somewhere. Reporting Services loading is the same.
God-awful slow but once its resident, its OK. But hey, don't undock and
move a property window! On this score (IDE-wise) VO is an order of
magnitude faster in just about everything: editing, incremental
compiles, exe gen, you name it.
Post by Graham McKechnie
haven't done that here for a while. Dual core these days, I suppose you
don't like them either..
<shrug> They don't impress me because they are so slow. Most are about
1.6Ghz and the expensive ones are around 2Ghz. So what! They are almost
technically equivalent to HT so what's the beef? They can get you at
most around a 25% increase in general performance but only for
applications that launch multiple threads and actively manage the
threads. If all you do is launch a thread in the same memory space as
the main app then you are just competing for the same resource. And how
many apps really manage by thread? Even Outlook is particularly poor. VS
is atrocious. Watch it in the task manager some time.

My current 3.2Ghz P4 is hyperthreaded - which means it is on a par with
a dual core. So why would I want to ditch one third or more of my
processor speed? In the case of most laptops, it means they run at
exactly HALF my laptop speed. I don't think most people understand where
the bottleneck is because usually its not the processor. It's the
database and bus governor feeding the processor - two cores only adds an
overhead that slows down a single threaded app. It only improves a
multi-threaded app when there is work that can be properly arbitrated
out to two processors or more.
Post by Graham McKechnie
You've got a thing about this docking stuff, haven't you? I really don't
understand, I spend most of the day with the editor taking up all the
<g> Work with Reporting Services for a while.
Post by Graham McKechnie
Well you know I'm not going to agree with you there. I'd rather spend time
in the design phase, get the class design right. If it requires a couple
Well I won't argue with that because not enough of us do it anywhere
near enough of the time. As I've said a dozen times already, I am
totally comfortable with C# and I am learning to adapt to VS and it's
foibles. No problem. But when the discussion turns into what is faster
or easier I can make the statements I have with certainty. Don't read it
as a criticism of VS or I'll start calling you Johel <g>.
Post by Graham McKechnie
Guess what, I'm not trying. I've already convinced the only guy that
matters here.
<g> good quote

Cheers.

Geoff
Graham McKechnie
2006-06-11 23:21:23 UTC
Permalink
Geoff,
No its not, in fact the same difficulties arise with DLL management for VS
just as much as VO.
There is no dll management in VS. You place some code in a dll and simply
keep going, debugging it, if you want to. Not at all like VO.
my solution in VO was to make one huge app and from what I see with VS,
that tends to be the way I see most people coding.
Sorry I don't go with the one big app thing. Just take a look at your list
again for the reasons, rather than me repeat them again. You previously said
you use Infragistics, how many dll's there? Have you stepped through their
code?
They don't impress me because they are so slow. Most are about 1.6Ghz and
the expensive ones are around 2Ghz.
I'll let Stark, carry on from here. He's the resident hardware man around
here. I'm not due for a new machine for another couple of months, so I
haven't got around to looking at this new stuff.

Graham
Graham,
Yeh, I wake up every morning and the dog reminds me.<g> .
Don't kick it then... <g>
That is contradictory to what you just stated about using dll's with VO in
your previous post - the one I was replying to. Nothing like changing tack
No its not, in fact the same difficulties arise with DLL management for VS
just as much as VO. The only point I will concede is error handling into
the debugger is a generation better than VO but most other aspects suffer
the same issues as all IDEs. As I said, my solution in VO was to make one
huge app and from what I see with VS, that tends to be the way I see most
people coding.
Can't imagine how if you spend your whole day reindexing the repo.
Well let's not overdo it. The reindex takes about 4 seconds. A full
recompile about 3 minutes (but I only need to do this once every couple of
days). I might add here that a VS full recompile takes a helluva lot
longer than a VO compile for the same amount of code - even VS 2003! In
fact, sometimes the IDE goes into go-slow and starts doing a VO on my.
great difference. I thought you had a fast machine!!!! Maybe time to buy
setting up buffers somewhere. Reporting Services loading is the same.
God-awful slow but once its resident, its OK. But hey, don't undock and
move a property window! On this score (IDE-wise) VO is an order of
magnitude faster in just about everything: editing, incremental compiles,
exe gen, you name it.
haven't done that here for a while. Dual core these days, I suppose you
don't like them either..
<shrug> They don't impress me because they are so slow. Most are about
1.6Ghz and the expensive ones are around 2Ghz. So what! They are almost
technically equivalent to HT so what's the beef? They can get you at most
around a 25% increase in general performance but only for applications
that launch multiple threads and actively manage the threads. If all you
do is launch a thread in the same memory space as the main app then you
are just competing for the same resource. And how many apps really manage
by thread? Even Outlook is particularly poor. VS is atrocious. Watch it in
the task manager some time.
My current 3.2Ghz P4 is hyperthreaded - which means it is on a par with a
dual core. So why would I want to ditch one third or more of my processor
speed? In the case of most laptops, it means they run at exactly HALF my
laptop speed. I don't think most people understand where the bottleneck is
because usually its not the processor. It's the database and bus governor
feeding the processor - two cores only adds an overhead that slows down a
single threaded app. It only improves a multi-threaded app when there is
work that can be properly arbitrated out to two processors or more.
You've got a thing about this docking stuff, haven't you? I really don't
understand, I spend most of the day with the editor taking up all the
<g> Work with Reporting Services for a while.
Well you know I'm not going to agree with you there. I'd rather spend time
in the design phase, get the class design right. If it requires a couple
Well I won't argue with that because not enough of us do it anywhere near
enough of the time. As I've said a dozen times already, I am totally
comfortable with C# and I am learning to adapt to VS and it's foibles. No
problem. But when the discussion turns into what is faster or easier I can
make the statements I have with certainty. Don't read it as a criticism of
VS or I'll start calling you Johel <g>.
Guess what, I'm not trying. I've already convinced the only guy that
matters here.
<g> good quote
Cheers.
Geoff
GSchaller
2006-06-11 23:49:50 UTC
Permalink
Graham.
Post by Graham McKechnie
There is no dll management in VS. You place some code in a dll and simply
keep going, debugging it, if you want to. Not at all like VO.
Hmmm, well I don't think it is the same thing and the physical
separation is totally different. I suspect you and I manage "projects"
differently here, both for VO and for VS. It is a bit confusing to
discuss like this here.
Post by Graham McKechnie
you use Infragistics, how many dll's there? Have you stepped through their
code?
Oh boy, don't start me. It is a HUGE PITA so you lose on this one. Code
hunting is one of the WORST aspects of VS and one of my biggest time
wasters. I hate it with a passion (because I've been spoilt with VO) but
I have to live with it. And don't start me on editors and windows sizes
<g>. You've already said you run your code editor full screen so I am
left to ponder how you traverse property windows and code lists...

Having 300,000 lines of code in the one editor is daunting, sorry <g>.

Regards,

Geoff
Graham McKechnie
2006-06-12 00:31:29 UTC
Permalink
Geoff,
Hmmm, well I don't think it is the same thing and the physical separation
is totally different.
It sure is in VO. Different and complicated - that is.
Oh boy, don't start me. It is a HUGE PITA so you lose on this one.
How do I lose on this one? I'm not talking about code hunting. I thought we
were talking about dll's and debugging, the subject of the thread.
Code hunting is one of the WORST aspects of VS and one of my biggest time
wasters.
On the subject of code hunting - you're only a right click away - either Go
To Definition or Find All References. The object browser is another useful
tool. Or do you mean something else.
Post by GSchaller
I hate it with a passion (because I've been spoilt with VO)
Well in my days with VO, one wasn't spoilt with anything. Other words do
come to mind though.
Having 300,000 lines of code in the one editor is daunting, sorry <g>.
Well I don't have 300,000 lines in one editor. Seems like that might be part
of your management problem.
You've already said you run your code editor full screen so I am left to
ponder how you traverse property windows and code lists...
I click on them Geoff, when I need them. Everything is available from the
Solution explorer, which is always available. Even your beloved Properties
Window is only a click away. Not much in at, if you are looking at code, but
its there. You sure you've got the hang of how this IDE works?
Post by GSchaller
code lists...
What do you define as a code list? I'm not following with that term.

Graham
Graham.
Post by GSchaller
There is no dll management in VS. You place some code in a dll and simply
keep going, debugging it, if you want to. Not at all like VO.
Hmmm, well I don't think it is the same thing and the physical separation
is totally different. I suspect you and I manage "projects" differently
here, both for VO and for VS. It is a bit confusing to discuss like this
here.
Post by GSchaller
you use Infragistics, how many dll's there? Have you stepped through their
code?
Oh boy, don't start me. It is a HUGE PITA so you lose on this one. Code
hunting is one of the WORST aspects of VS and one of my biggest time
wasters. I hate it with a passion (because I've been spoilt with VO) but I
have to live with it. And don't start me on editors and windows sizes <g>.
You've already said you run your code editor full screen so I am left to
ponder how you traverse property windows and code lists...
Having 300,000 lines of code in the one editor is daunting, sorry <g>.
Regards,
Geoff
GSchaller
2006-06-12 03:14:52 UTC
Permalink
Graham,
Post by Graham McKechnie
On the subject of code hunting - you're only a right click away - either
Go To Definition or Find All References. The object browser is another
useful tool. Or do you mean something else.
No. I find all these tools annoying and slow. The VO IDE has a much
better layout of apps, modules and dependencies. Code or otherwise. The
object browsers work but they are too small and always overcrowded.
Post by Graham McKechnie
I click on them Geoff, when I need them. Everything is available from the
Solution explorer, which is always available. Even your beloved Properties
Window is only a click away. Not much in at, if you are looking at code, > its there. You sure you've got the hang of how this IDE works?
Absolutely. 'clicking' is not enough. It's all about availability. I
have to find the object I want first and that is the drama. VS has not
got this part of the process right. Perhaps you don't need to move
around your code base as much as I seem to need to.
Post by Graham McKechnie
What do you define as a code list? I'm not following with that term.
I want to look up code. Finding the code is the hard part. The 'lists' I
refer to I mean as the object browsers. Gimme back the VO treeview <g>.

Geoff
Graham McKechnie
2006-06-12 04:06:07 UTC
Permalink
Geoff,
Post by GSchaller
No. I find all these tools annoying and slow.
You select, you right click, and you are there - is that slow? Its bloody
instantaneous on my machine.
Post by GSchaller
Absolutely. 'clicking' is not enough. It's all about availability. I have
to find the object I want first and that is the drama. VS has not got this
part of the process right. Perhaps you don't need to move around your code
base as much as I seem to need to.
Perhaps I don't have to move around my code base as much as you, because it
is better laid out than yours and I know exactly where things are, by the
descriptive name of the Namespace. You are using Namespaces I hope to
organise modules as you call them? Every folder off the project node can
(doesn't have to) become a Namespace.
Post by GSchaller
I want to look up code. Finding the code is the hard part. The 'lists' I
refer to I mean as the object browsers. Gimme back the VO treeview <g>.
Geoff, Solution Explorer is a Treeview. You can create as many sub folders
as you want off the project node. I fail to see how you can't organise your
code structure the way you want using Solution Explorer. A Treeview is a
Treeview, be it VO or VS.

I think I'd have to look at how you are doing it, but it seems weird to me
that you are having these problems. As far as I'm concerned, organising code
structure in VS is light years ahead of what I used to put up with VO. VO's
rules were governed by the repo, i.e fixed - VS rules are lay it out where
and however you like.

If you really are having all these problems I could always drop over and
show you how I do it. My way of course might not suit you, but at least
you'd see how it can be done. Having said that I don't think my way is any
different to how I see other people organise their projects in C#.

I started last week on an existing project, that I'd never seen before, the
other guy just gave me the project and I was finding my way around it within
minutes. It was completely intuitive, just following the namespace names.

Graham
Post by GSchaller
Graham,
Post by Graham McKechnie
On the subject of code hunting - you're only a right click away - either
Go To Definition or Find All References. The object browser is another
useful tool. Or do you mean something else.
No. I find all these tools annoying and slow. The VO IDE has a much better
layout of apps, modules and dependencies. Code or otherwise. The object
browsers work but they are too small and always overcrowded.
Post by Graham McKechnie
I click on them Geoff, when I need them. Everything is available from the
Solution explorer, which is always available. Even your beloved Properties
Window is only a click away. Not much in at, if you are looking at code,
Post by Graham McKechnie
its there. You sure you've got the hang of how this IDE works?
Absolutely. 'clicking' is not enough. It's all about availability. I have
to find the object I want first and that is the drama. VS has not got this
part of the process right. Perhaps you don't need to move around your code
base as much as I seem to need to.
Post by Graham McKechnie
What do you define as a code list? I'm not following with that term.
I want to look up code. Finding the code is the hard part. The 'lists' I
refer to I mean as the object browsers. Gimme back the VO treeview <g>.
Geoff
GSchaller
2006-06-12 04:32:19 UTC
Permalink
Graham,
Post by Graham McKechnie
You select, you right click, and you are there - is that slow? Its bloody
instantaneous on my machine.
IT'S THE SELECTING BIT! <g>
Post by Graham McKechnie
is better laid out than yours and I know exactly where things are, by the
descriptive name of the Namespace. You are using Namespaces I hope to
organise modules as you call them? Every folder off the project node can
(doesn't have to) become a Namespace.
Nothing to do with namespaces. It's the simple volume of classes and
entities and how they're organised. Just throw in the infragistics
library and review the mess!
Post by Graham McKechnie
code structure the way you want using Solution Explorer. A Treeview is a
Treeview, be it VO or VS.
It's too small and it's a pane. If you undock and move it it's too slow
and in the way. 2 monitors is now 100% essential to do anything
reasonable and I'm starting to think I need 3.
Post by Graham McKechnie
If you really are having all these problems I could always drop over and
show you how I do it. My way of course might not suit you, but at least
I am absolutely always interested in looking at how other people use
these various tools and always willing to accept that 'our way' may not
be the best. I will take you up on the offer and will have some 12yr
Glen Morange ready to lubricate discussion. I'd offer some 18yr but Ed
drank it all <g>.

Geoff

Amilcar A. Camargo
2006-06-10 15:41:53 UTC
Permalink
Hi Phil,
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
An easy way to do this: add your dll as a library into your app and
debug. When you're done with it, remove the library, build the DLL and
add the DLL aef to your app.

For example, you have a DLL in your project named MyFirstDLL that
generates a file "First.dll". While you're developing and debugging,
add 'MyFirstDll' to your app libraries (there is no need to change
MyFirstDll type from DLL to library). When you're finished with it,
remove from it from your app properties, generate the DLL and add
'First DLL.aef' to your project and then, add it to your app.

HTH,
Amilcar A. Camargo F.
Sand, S. A.
Guatemala, C. A.

(pls remove _no_ to e-mail)
Will Chapman
2006-06-10 20:13:12 UTC
Permalink
Post by Amilcar A. Camargo
An easy way to do this: add your dll as a library into your app and
debug. When you're done with it, remove the library, build the DLL and
add the DLL aef to your app.
Amilcar

That works sometimes but not always. For example, I have
an OCX tool that is used by 3rd parties and the lib before
dll approach doesn't work for all the functionality.

I think its best to get the VOM approach running and do
it that way.

Cheers...

Will Chapman
Amilcar A. Camargo
2006-06-11 19:15:50 UTC
Permalink
Hi Will,

On Sat, 10 Jun 2006 21:13:12 +0100, Will Chapman
Post by Amilcar A. Camargo
Post by Amilcar A. Camargo
An easy way to do this: add your dll as a library into your app and
debug. When you're done with it, remove the library, build the DLL and
add the DLL aef to your app.
Amilcar
That works sometimes but not always. For example, I have
an OCX tool that is used by 3rd parties and the lib before
dll approach doesn't work for all the functionality.
I think its best to get the VOM approach running and do
it that way.
Thanks for pointing this out.

Regards,
Amilcar A. Camargo F.
Sand, S. A.
Guatemala, C. A.

(pls remove _no_ to e-mail)
GSchaller
2006-06-11 02:21:15 UTC
Permalink
Amilcar,

That will not work except in the simplest of application designs and if
your app was that simple, I would contend that you didn't need the DLL
in the first place.

If you have more than one library referencing that DLL you would need to
make all dependent application units refer to the library. Better to
make the entire application one huge app, do your debugging and then
unhinge it back to dll's again.

However, the process I described does work and Robert demonstrated at a
conference 18 months ago. This is where conference attendance by more
people would have helped enhance the VO community. Experience with such
things is hard to come by these days.

Geoff
Post by Amilcar A. Camargo
Hi Phil,
Post by Phil Mermod
Hi VO'ers,
I want to debug a library which is used in an app (exe) and a dll. It seems
impossible after calling a class....
An easy way to do this: add your dll as a library into your app and
debug. When you're done with it, remove the library, build the DLL and
add the DLL aef to your app.
For example, you have a DLL in your project named MyFirstDLL that
generates a file "First.dll". While you're developing and debugging,
add 'MyFirstDll' to your app libraries (there is no need to change
MyFirstDll type from DLL to library). When you're finished with it,
remove from it from your app properties, generate the DLL and add
'First DLL.aef' to your project and then, add it to your app.
HTH,
Amilcar A. Camargo F.
Sand, S. A.
Guatemala, C. A.
(pls remove _no_ to e-mail)
Amilcar A. Camargo
2006-06-11 19:52:38 UTC
Permalink
hi Geoff

On Sun, 11 Jun 2006 02:21:15 +0000, "GSchaller"
Post by GSchaller
Amilcar,
That will not work except in the simplest of application designs and if
your app was that simple, I would contend that you didn't need the DLL
in the first place.
If you have more than one library referencing that DLL you would need to
make all dependent application units refer to the library. Better to
make the entire application one huge app, do your debugging and then
unhinge it back to dll's again.
Well, if you have to debug a dll with so much referencing app's and
libraries, the question becomes: how that piece of code became a dll
without being fully tested?.

I always start with a library and, when it complies with all the
design requeriments, it becames a "black box" and is converted to a
dll if will be shared between more than one app or dll.

Of course, there are situations were your approach is the only one
alternative. Mostly when you have to deal with app made by others,
being it whole app's or dll's.

And also, as stated by Will Chapman, COM objects in VO need a special
treatment to being debugged.

Regards,
Amilcar A. Camargo F.
Sand, S. A.
Guatemala, C. A.

(pls remove _no_ to e-mail)
GSchaller
2006-06-11 22:58:07 UTC
Permalink
Hi Amilcar.
Post by Amilcar A. Camargo
Well, if you have to debug a dll with so much referencing app's and
libraries, the question becomes: how that piece of code became a dll
without being fully tested?.
<g> Wouldn't that be nice in the perfect world. So I guess then you
never had to add new functionality to a delivered DLL and of course this
is when the problem starts.
Post by Amilcar A. Camargo
I always start with a library and, when it complies with all the
design requeriments, it becames a "black box" and is converted to a
dll if will be shared between more than one app or dll.
...and never touched again? <g>
Post by Amilcar A. Camargo
And also, as stated by Will Chapman, COM objects in VO need a special
treatment to being debugged.
Ah, yes. Certainly COM objects need their own love, care and attention
but you can still debug into your own source code and I presume that is
what this thread is all about.

Look, I agree with Graham, this is all very messy and bug hunting is
always a PITA. But it can be done and all I'd like to assure folks is
that there are several ways of dealing with it.

Cheers,

Geoff
Loading...