headers
Sheri | 1 Jul 2009 02:06
Picon

Re: convert VB script to PP

--- In power-pro@..., "quantiworks" <quanticworks <at> ...> wrote:
>
> > I was responding to this message:
> > 
> > <http://tech.groups.yahoo.com/group/power-pro/message/35609>
> > 
> > where you said you were able to see the label you wanted in the debug window.
> 
> Yes, I can see the label in the debug console if I execute the
> script manually (double-clicking it)
> 
>  If you can no longer debug the label, there is no point in
>  continuing. Otherwise, instead of debugging, you need to put the
>  label into a variable and use: quit(variable) 
> 
> That's what I did following your string suggestions but doesn't
> work. 

The result of com.create_object should be assigned to a static variable so it can be reused (i.e., if it
already exists, it shouldn't be recreated). You should debug the scriptlet and get it working before
trying to use it in info expr. From info expr it is likely getting rerun very frequently. Unless using a
static variable, it likely needs "com.release(iTunesApp)" and some way to make sure the release is
completed before the script gets re-executed.

Regards,
Sheri

Regards,
Sheri
(Continue reading)

Permalink | Reply | 0 comments |
headers
swzoh | 1 Jul 2009 02:44
Picon

Re: com 0.63 090627

--- In power-pro@..., "entropyreduction"
<alancampbelllists+yahoo <at> ...> wrote:
>
> Reinstated in latest version, main thread only.

I'd rather use for both threads, although it may not be absolutely necessary for the worker thread.

> > Anyway, I'd rather wait on hThread than hEvent when PP is shutdown.
> 
> For some reason WaitForSingleObject(hThread) locks up.  I'll try
> CoWaitForMultipleHandles with hThread.
>

Just in case, I meant hThread should be that of the worker thread,
WaitForSingleObject/CoWaitForMultipleHandles on the main thread. BTW, I suppose it'd work only in
case of PP's ExitProcess, not likely in case of mere com.unload. So, ultimately you may have to pursue as
Bruce suggested.

------------------------------------

Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/power-pro/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/power-pro/join
(Continue reading)

Permalink | Reply | 2 comments |
headers
swzoh | 1 Jul 2009 03:41
Picon

Re: com 0.63 090627

--- In power-pro@..., "Sheri" <sherip99 <at> ...> wrote:
>
> Ctfmon.exe is not exclusively part of Office XP (Office XP is partly the subject of the link). It is run by
the operating system for the text services and the language bar. These services are needed if you use Asian fonts.
> 

FYI, ctfmon.exe is disabled in my system. No problem to use Asian characters. It'll just disable some
(supposed) advanced text services.

------------------------------------

Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/power-pro/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/power-pro/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:power-pro-digest@... 
    mailto:power-pro-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    power-pro-unsubscribe@...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sheri | 1 Jul 2009 14:30
Picon

Re: com 0.63 090627

--- In power-pro@..., "swzoh" <seanzoh <at> ...> wrote:
>
> --- In power-pro@..., "Sheri" <sherip99 <at> > wrote:
> >
> > Ctfmon.exe is not exclusively part of Office XP (Office XP is
> > partly the subject of the link). It is run by the operating
> > system for the text services and the language bar. These services
> > are needed if you use Asian fonts. 
> 
> FYI, ctfmon.exe is disabled in my system. No problem to use Asian
> characters. It'll just disable some (supposed) advanced text
> services. 

I can disable it in the Regional/Language Control Panel applet, but the checkbox says:

> Turn off advanced text services: Select this checkbox to turn off
> advanced text services in all programs. Not recommended for East
> Asian users because this closes the language bar.

So disables the IME. Isn't that needed by most Asian users?

Actually this MSDN article suggests that even more than the checkbox is required to completely disable it:

http://support.microsoft.com/kb/282599

Just was searching for a possible explanation why Alan and Bruce seem to be able to run the plugin scripts
without the same issues as the rest of us.

Regards,
Sheri
(Continue reading)

Permalink | Reply | 1 comment |
headers
brucexs | 1 Jul 2009 17:37
Picon
Favicon

Re: com 0.63 090627


> 
> Just was searching for a possible explanation why Alan and Bruce seem to be able to run the plugin scripts
without the same issues as the rest of us.

Fair enough, but IMHO, data like debug traces are much more valuable then speculation, at this point.

------------------------------------

Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/power-pro/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/power-pro/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:power-pro-digest@... 
    mailto:power-pro-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    power-pro-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
(Continue reading)

Permalink | Reply | 0 comments |
headers
entropyreduction | 1 Jul 2009 18:03

Re: com 0.63 090627

At the moment, design is: thread is launched, and waits on event.

When there's something to do (aka a com service to perform), main thread sets up some stuff (mainly a pointer
to a object that knows how to do that service), sets the event that gets the worker thread out of its wait, and
then itself waits on another event.  When the
worker thread has finished it's thing, it sets the event that lets the main thread run, and goes back to
waiting for the next thing to do.

Finishing is just "another thing to do" for the worker thread, and follows same pattern.

--- In power-pro@..., "brucexs" <bswitzer <at> ...> wrote:

> > For some reason WaitForSingleObject(hThread) locks up.  I'll try
> > CoWaitForMultipleHandles with hThread.

> Possibly the code in the file plug-in in dll_detach may be give you some helpful ideas.  It is shutting down
any threads which are in wait state from file.runwait.  

I get by waiting for the "there's stuff to do" event in the worker thread.  In the special case where the
pointer to the object that knows what specifiically to do is null pointer, the thread ends.

> I understand that you have the same situation that a worker thread may be in the wait state and you need to
shut it down.  This code does that.

> If your worker thread is not normally in the wait state, then would need to augment this idea.  For PowerPro,
if the thread happened not to be in the wait state, now that I look at it, there is actually a potential
deadlock, since the thread's function could sendmessage to powerpro itself (ie the thread that has just
send an event and is now wait for thread to die).  I should be checking for the unload event before that, but it
seems this error has never been reported so I am assuming it is too rare to worry about.  Possibly not the
situation for you.
(Continue reading)

Permalink | Reply | 2 comments |
headers
entropyreduction | 1 Jul 2009 18:07

Re: com 0.63 090627

Problem with setting a vector might be: when do you look at it?
If all goes well, all goes well.  If all goes badly and powerpro locks up, there's no way to look at the trace
vector.  

However, can't hurt to try.  Will do in a day or so.

--- In power-pro@..., "brucexs" <bswitzer <at> ...> wrote:
>
> > What about debug calls right at various points in worker thread shutdown (.e.g called to clean up,
completed cleanup and exiting) and then in dll shutdown to see if order of calls varies on different machines?
> 
> BTW, would probably want to avoid doing actual I/O since it may screw up ordering.  Maybe set a static vector
vector 
> nextwas[global_index++]=icode
> where icode varies depending on point in code being traced.  Could use interlocked increment for
global_index to be safe.  Then output nextwas just before dll exit.
> 
> 
> 
> 
> >
>

------------------------------------

Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/power-pro/
(Continue reading)

Permalink | Reply | 1 comment |
headers
entropyreduction | 1 Jul 2009 18:14

COM plugin 0.63_090630, COM plugin 0.63_090701

I thought I posted a message about COM plugin 0.63_090630 yesterday, but guess not.

COM plugin 0.63_090630: replaced WaitForSingleObject with CoWaitForMultipleHandles.  Killed call to
OleUninitialize for now

COM plugin 0.63_090701: as above, and put some critcal section fences around some stuff that shouldn't, in
principle need it, but....

------------------------------------

Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/power-pro/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/power-pro/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:power-pro-digest@... 
    mailto:power-pro-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    power-pro-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Permalink | Reply | 0 comments |
headers
entropyreduction | 1 Jul 2009 18:16

Re: com 0.63 090627

--- In power-pro@..., "swzoh" <seanzoh <at> ...> wrote:
>
> --- In power-pro@..., "entropyreduction"
<alancampbelllists+yahoo <at> > wrote:

> > Reinstated in latest version, main thread only.

> I'd rather use for both threads, although it may not be absolutely necessary for the worker thread.

Worker thread appeared to lock up if I tried it there.

> > > Anyway, I'd rather wait on hThread than hEvent when PP is shutdown.
> > 
> > For some reason WaitForSingleObject(hThread) locks up.  I'll try
> > CoWaitForMultipleHandles with hThread.

> Just in case, I meant hThread should be that of the worker thread,
WaitForSingleObject/CoWaitForMultipleHandles on the main thread. 

Tried that in COMplugin0.63_090630.zip, forgot to mention in parallel post.  Seems to work.

> BTW, I suppose it'd work only in case of PP's ExitProcess, not likely in case of mere com.unload. So,
ultimately you may have to pursue as Bruce suggested.

unload is meant to kill the worker thread, so have to cause thread to exit and wait on it during unload.

------------------------------------

Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links
(Continue reading)

Permalink | Reply | 1 comment |
headers
brucexs | 1 Jul 2009 21:12
Picon
Favicon

Re: com 0.63 090627

--- In power-pro@..., "entropyreduction"
<alancampbelllists+yahoo <at> ...> wrote:
>
> Problem with setting a vector might be: when do you look at it?
> If all goes well, all goes well.  If all goes badly and powerpro locks up, there's no way to look at the trace
vector.  
> 
> However, can't hurt to try.  Will do in a day or so.

True.  But when I posted, most people were saying the version they had worked once, but could not be run again. 
It would be interesting to know if there is something consistently different about the order of events in
the cases this happens.  Sheri also reported getting inconsistent results by starting the program a
different way.  Not sure if that was truly the cause, or if it was just random luck in some race condition.  But
I personally have more luck with debugging traces guided by theorizing, then from just theorizing.

For the case when it locks up, you could have a setup call like 
com.dump(stop#)
which would stop and dump at step number stop# if stop#>0.  Start with 0 and if it blocks, tell people to keep
working backwards from n until you get a dump (where n is highest step you have set up in your code.)  Of course
do this several times to find a pattern. 

------------------------------------

Attention: PowerPro's Web site has moved: http://www.ppro.orgYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/power-pro/

<*> Your email settings:
    Individual Email | Traditional
(Continue reading)

Permalink | Reply | 0 comments |

Gmane