Re: Walkthrough Instruction Error

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Wolfgang Enzinger" <usenet200812@xxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:03es35tn8f8aaib7h1r63bsoam5tdfaafg@xxxxxxxxxx
On Sun, 21 Jun 2009 23:03:22 +1000, "Bill McCarthy" <TPASoft.com Are
Identity Thieves> wrote:

When I recommended to study MTAX2.zip, I wrote: "Compile. Start
MTAX.exe. Start your Taskmanager. Click the button. Watch.". Silly me, I
assumed your were able to follow these simple instructions.


Well what you didn't say was that your code couldn't be run from the IDE.
It was only *after* I reported back here the issues with your code when run
from the DIE you admitted it couldn't be run from the IDE.

Now that is funny ... you didn't do with it what you were told, and then
you "reported back there were issues" so that I had to "admit" ...

Listen: I also failed to mention that you have to unzip *all* files
before you load them ... so if you had unzipped only one file and
reported back that it doesn't compile, then I would have had to "admit"
that this is another limitation of my project, right?


LOL. The *facts* are you never said **anything** at all about not being able to run it in the IDE. There were no comments or anything in the code to suggest you couldn't. It was only since I pointed out the issues if you did, you then admitted to that **MAJOR** limitation. In the actually real **meaning** of the discussion, that limitation is very significant.


This is plain ridiculous. Are you sure you really are a developer?


Huh ? first, I think most developers woudl open the code and expect to run it. what kind of developer are you that doesn't docuemnt such limitations ? Is that how you share work with your team ? Have you never heard of docuemtning the code ?? You seemed to put a lot of useless comments in the code, but nothign in there ot suggest nto to run it form the IDE. It's as if you were trying to hide that lmitation.



LOL. By "properly" you mean a message box saying it can't be run in the
IDE.

You know that's not true. It's not saying it can't be run in the IDE, it
says: "in IDE, single threaded; compile for multithreading experience".


Oh this is just nonsense. The Multi threading cannot be run in the IDE. In fact in your first code, if you ran it from the IDE the reference count in the collection was never decremented, so there were always pending jobs reported even though those jobs couldn't run. And if that wasn't bad enough, becuase you coudln't properly exit out you have to force the debugger to stop, and then it won't run agian because you were setting properties on the Desktop window.



This MessageBox was integrated for those who are unable to understand
what I told them before - so far I only see one with this problem.
Anyway, the code can be run, debugged and edited at runtime in the IDE.


Utter nonsense. It cannot, and you know it. The threads do not run. This is really disingenuous of you to claim otherwise.


Look at the code again. The significant change I made was that I
disabled the discoupling while the code runs in the IDE cause it makes
no sense in a single-threaded scenario.


I really don't care which of the issues you now say you have addressed. The facts remain you cannot debug the *real* code *properly* with your approach.

I am really amazed anyone would use such an approach, little less distribute the code like you originally posted. Let me guess, you use ot tell people oh sorry you can't restart the app, you have to restart windows ??


I suggest you read the documentation on Asynchronous programming in VB6,
where your VB6 applciation uses CreateObject for objects that are in an
activex.exe.

I suggest you answer my questions:

* Can you tell me where the second process is and what its name is?

* Why do the additional threads show up with the MTAX.exe process entry
in TaskManager if they are out-of-process?

Can you answer these?


You know, you still haven't listened to a thing that has been said to you, have you ? Instead of reading the documentation or going back and reading the things I said to you that you obviously skipped, you still think the significant part of this discussion is about whether or not it is in or out of process. I answered that before you even posted a link to a working zip. But just to be nice, I'll repeat the main points again for you. Whether or not it is in process or out of process is in itself insignificant, what is important is the overhead of marshalling and synchronization. The only advantage out of process has is it doesn't necessarily pull the app down if it crashes. So what exactly do you think the **REAL** issue about out of process is ? It is of course about the overhead.

So I asked you about what marshalling you think is occurring in your app. to which you replied you don't know. so you have an app that's compiled as an activex.ex, can't debug it, and based on your code you say you'd been using since VB5, if your app crashed the user would have to restart windows, and you can't tell me if there is or isn't any overhead difference ?? Do you really think there's no synchronization, no marshalling, no queuing ? What about thread deadlocks ? Race conditions ? Is that being handled for you or not ?

So moving aware from silly parlor games.... Something tells me you will continue on this silly track of yours even though I first told you it wasn't an issue of in process or out of process (yes **do** actually go back and read what I first wrote to you) In the scope of the real discussion, where I was , before you and Olaf interrupted, talking about the road well travelled, I think all that out have shown actually re-enforces what I was saying. The best you have been able to throw up is an app you can't debug, and you can't even tell us why you would do that rather than call on a activex.exe as per the usual documented way. At least then you could run the activex.exe in one instance of VB6 and your app in another.

What you've done is not even focus on a tree, but instead on a blade of grass, and in doing so ignored the entire forest. You can't even tell us if marshalling is occurring in your app. I think the only possible reason you'd use your hack is to keep the app a single file, but even then it has to be registered, so you need to distribute it with a setup program. Considering how much you loose, and considering how bad your original sample was, the one you said you've been using since VB5, I'd expect such usage to have some good reasons: yet you haven't mentioned a one. Fro ma business perspective the issues are performance, robustness, code maintenance and development costs. You've failed on 3/out of 4 of those *badly*, and on the performance or overhead issue you said you don't know. Road well travelled versus parlor tricks.














.

Relevant Pages

  • Re: You finally beat me down
    ... I have spent a number of years developing a certain app ... ... installing components crash the IDE? ... Your stock VCL controls lack the most basic functionality. ... native app to build, it will be in WTL/wxWidgets or QT. ...
    (borland.public.delphi.non-technical)
  • Re: App.EXE Wont Run
    ... They all run just fine in the IDE. ... Never get to the first line in Sub Main. ... app although I do see how MS does some strange and interesting things. ... Second the two major differences between a stand-alone exe and running ...
    (microsoft.public.vb.general.discussion)
  • Re: Great SWT Program
    ... functionality I'll use a *real* IDE like Eclipse. ... emacs, but eclipse is also a vastly superior IDE with, particularly, a ... then I don't need the app to be able to do ... Running it 1000 times in a loop makes this especially visible. ...
    (comp.lang.java.programmer)
  • Re: How to debug an ActiveX DLL
    ... You don't even need the main application in the IDE Dag. ... Just loaded the VB project for the DLL into the IDE, ... instruct it to run your main app whenever you want to debug the VB DLL. ... I'm a real novice when it comes to ActiveX DLLs, ...
    (comp.lang.basic.visual.misc)
  • Re: What Smalltalk product/implementation would you use, and why?
    ... no matter what language or implementation you use. ... complexity of the GUI, the complexity of the code which manages the GUI, and ... I don't know how much overhead other Smalltalk ... app will start up fast enough for startup time not to be noticeable. ...
    (comp.lang.smalltalk)