[SOLVED] Task Schreduling in Windows 7 (API ver. 2) ??

[nicke85]

Actually the most interesting is that i work project in D2007 but want to find and share solution
on Lazarus community because Pascal is a Pascal and I like FPC.
Here is a my post on Embarcadero forum and nobody didn't help me anyway.
Just to everybody know that!!!!

If you can explain how to use bindings from your D6 solution I will appreciated.

[marcov]

I found a description of TLB files btw. Would that help for early binding?

The mstasks.pas wrapper is already the interface definition for API 1.0. FPC early binding with 1.0 was already possible.
Using D6 I created the bindings for API 2.0 but that needs some tweaking to get it working with fpc. If anybody is interested I can do that. It won't help in creating common code for the 2 API's though.

I meant as a step in the direction of an own importer. So not the use of early bindings, but the generation of them.

[ludob]

I meant as a step in the direction of an own importer. So not the use of early bindings, but the generation of them.

An equivalent to the Delphi Import Type Library tool you mean.  Is there any interest for that? COM and ActiveX are not very popular in the fpc community.
Delphi has abandoned support for TLB files since D2009. Don't know what the reason was. The TLB spec's I have are pretty much reverse engineered ones. MS OleView does the conversion TLB to IDL. I think it would be wiser, if the need exists, to create an IDL to fpc importer.

[marcov]

I meant as a step in the direction of an own importer. So not the use of early bindings, but the generation of them.

An equivalent to the Delphi Import Type Library tool you mean. 

Yes.

Is there any interest for that?

I think there are two or three threads in the last couple of months alone where people say they use Delphi for it. Not healthy. Also, a FPC version will make the generated source usable without mods, and make it possible to let the tool evolve with FPC, adding features as they emerge (like say fpdoc, but I think this is way simpler)

COM and ActiveX are not very popular in the fpc community.

It's only starting.

Delphi has abandoned support for TLB files since D2009. Don't know what the reason was.

Afaik their constant problems with the typelib editor. But that is on the creation site,  (creating TLBs), not on the TLB->source side.

They now base their stuff on an own IDL dialect, RIDL.

The TLB spec's I have are pretty much reverse engineered ones. MS OleView does the conversion TLB to IDL. I think it would be wiser, if the need exists, to create an IDL to fpc importer.

1) I'm not sure how usable the IDL is. They seem to have language specific emits everwhere.
2) The structure the IDL will be transformed too, will be pretty close to TLB, so the TLB->source is a good first step to get the feet wet.
3) As said there seem to be Microsoft (MIDL) and Embarcadero (RIDL) dialects.
4) I can be mistaken, but the IDL stuff is mostly developer side, with TLB being the format actually being shipped.
IOW TLB is afaik only deprecated as source format, not as the shipped format.

And to be frank, LALR parsers scare the hell out of me atm. I'm planning to first tackle some of the h2pas bugs before I would attempt creating such beast from scratch

Note that I only started researching this stuff yesterday, and most of my docs are old. I can easily be totally wrong, this is just the view I have now.

[ludob]

Code: [Select]

I think there are two or three threads in the last couple of months alone where people say they use Delphi for it. Not healthy.In the last months I dropped the D word in a com/activex context a few times Leaves us with how many others? My AcitveX & Evensink  demo has also inspired a few to make the jump.

1) I'm not sure how usable the IDL is. They seem to have language specific emits everwhere.

On the other hand, IDL is cross-platform. XPCOM, CORBA, etc, all use a flavor of IDL+extensions. The RIDL approach, support a subset of IDL, seems to be a good one. What, at first sight, seems to be downside of RIDL is that a basic MIDL has to be transformed to RIDL before being interpretable.

2) The structure the IDL will be transformed too, will be pretty close to TLB, so the TLB->source is a good first step to get the feet wet.

That is the internal representation after the parsing you mean, not the output.

4) I can be mistaken, but the IDL stuff is mostly developer side, with TLB being the format actually being shipped.
IOW TLB is afaik only deprecated as source format, not as the shipped format.

TLB is very "vendor" specific. XPCOM has .xpt files, etc. And yes, only Delphi is dropping support for TLB, not MS.

Code: [Select]

And to be frank, LALR parsers scare the hell out of me atm. I'm planning to first tackle some of the h2pas bugs before I would attempt creating such beast from scratch"From scratch" is the right word. I'm going to take a close look at the idl2pas implementation of the MT-DORB project. It is using yacc and lex. Currently it is "fed" with the CORBA IDL syntax, but if it works all right, it would be worth to give it a stab at "feeding" it with the MIDL syntax.

 

[marcov]

Code: [Select]

I think there are two or three threads in the last couple of months alone where people say they use Delphi for it. Not healthy.In the last months I dropped the D word in a com/activex context a few times Leaves us with how many others? My AcitveX & Evensink  demo has also inspired a few to make the jump.

A few. I track activex related topics already for 6 years :-)   Classic scenario is fast MS Office output, when generating large and many documents, the late binding overhead is noticable.

Though Sergei has done most of the work in the last two years.

1) I'm not sure how usable the IDL is. They seem to have language specific emits everwhere.

On the other hand, IDL is cross-platform. XPCOM, CORBA, etc, all use a flavor of IDL+extensions. The RIDL approach, support a subset of IDL, seems to be a good one. What, at first sight, seems to be downside of RIDL is that a basic MIDL has to be transformed to RIDL before being interpretable.

I expected that reaction. A general principle doesn't mean that they are common enough to be handled together. And if they aren't they might as well be different technologies for all intents and purposes.

And I'm not that interested in XPCOM and CORBA to begin with.  The uses are limited, except for Corba, but then you are probably doing Java, not FPC. Like I did when I did Corba ;-)

2) The structure the IDL will be transformed too, will be pretty close to TLB, so the TLB->source is a good first step to get the feet wet.

That is the internal representation after the parsing you mean, not the output.

Yes.

4) I can be mistaken, but the IDL stuff is mostly developer side, with TLB being the format actually being shipped.
IOW TLB is afaik only deprecated as source format, not as the shipped format.

TLB is very "vendor" specific.

True. So are VB and Office, but that doesn't prevent it from being used much, and the TLBs are the main way to access components from one and expose them to the other.

XPCOM has .xpt files, etc. And yes, only Delphi is dropping support for TLB, not MS.

I've no usecases for XPCOM, OpenOffice would be a better reason though.

Code: [Select]

And to be frank, LALR parsers scare the hell out of me atm. I'm planning to first tackle some of the h2pas bugs before I would attempt creating such beast from scratch"From scratch" is the right word. I'm going to take a close look at the idl2pas implementation of the MT-DORB project. It is using yacc and lex. Currently it is "fed" with the CORBA IDL syntax, but if it works all right, it would be worth to give it a stab at "feeding" it with the MIDL syntax.

I repeat: I'm not sure I can actually do anything with IDL, even if I had a working parser. Most activeX components are shipped with TLBs, not with the (M/R)IDL source from which the TLBs are generated.  IDL is only needed for a different (next) step, generating own activeX components. And afaik Embarcadero only abandonned TLB as the authoritive source in such case, not all together (as distributable container format, since again the RIDL compiler generates afaik TLBs)

Probably this is since VB6, Delphi and other activex consumers all eat TLBs.

Still thanks for the dorb mentioning. I had a look at it long ago, but maybe I should look at it with fresh eyes. But I stick to my original Christmas holiday planning, TLB first, then H2pas fixes, and then who knows :-)

[ludob]

you can explain how to use bindings from your D6 solution I will appreciated.

Attached the bindings for taskscheduler API 2 adapted for fpc. The Time Trigger example using late binding I made before becomes the following for early binding:

Code: [Select]

uses TaskScheduler_TLB
...
procedure TForm1.TimeTrigger2;
var TS:ITaskService;
  rootfolder:ITaskFolder;
  taskdefinition:ITaskDefinition;
  reginfo: IRegistrationInfo;
  principal:IPrincipal;
  settings:ITaskSettings;
  triggers:ITriggerCollection;
  trigger:ITrigger;
  action_:IAction;
begin
  TS:=CoTaskScheduler_.Create;
  TS.Connect(null,null,null,null);
  rootfolder:=TS.GetFolder('\');
  taskdefinition:=TS.NewTask(0);
  reginfo:=taskdefinition.RegistrationInfo;
  reginfo.Description:='Start Notepad';
  reginfo.Author:='Ludob';
  principal:=taskdefinition.Principal;
  principal.LogonType:=3;
  settings:=taskdefinition.Settings;
  settings.Enabled:=true;
  settings.StartWhenAvailable:=true;
  settings.Hidden:=False;
  triggers:=taskdefinition.Triggers;
  trigger:=triggers.Create(1);
  trigger.StartBoundary:='2011-12-19T18:30:00+01:00';
  trigger.EndBoundary:='2011-12-19T18:40:00+01:00';
  trigger.ExecutionTimeLimit:='PT5M';
  trigger.Id:='TimeTriggerId';
  trigger.Enabled:=true;
  action_:=taskdefinition.Actions.Create(0);
  IExecAction(action_).Path:='c:\Windows\system32\notepad.exe';
  rootfolder.RegisterTaskDefinition('Test TimeTrigger2',
         taskdefinition,6,NULL,NULL , 3,NULL);
end;
As you can see, al olevariants now become typed variables. More typing, but you get compile time checking of methods and properties. And far less run-time overhead. You have to pass always all parameters while late binding allows for default params.

 

[ludob]

The for each enumeration with early binding doesn't need the EnumVariant unit anymore. The enumtasks sample becomes now:

Code: [Select]

uses TaskScheduler_TLB,activex;

procedure TForm1.EnumTasks2;
var TS:ITaskService;
  rootfolder:ITaskFolder;
  taskcollection:IRegisteredTaskCollection;
  task:IRegisteredTask;
  enum:IEnumVariant;
  item:variant;
begin
  TS:=CoTaskScheduler_.Create;
  TS.Connect(null,null,null,null);
  rootfolder:=TS.GetFolder('\');
  taskcollection:=rootfolder.GetTasks(0);
  enum:=taskcollection._NewEnum as IEnumVariant;
  enum.Reset;
  while enum.Next(1,item)=S_OK do
    begin
    task:=IDispatch(item) as IRegisteredTask;
    memo1.lines.add(task.Name+' '+ inttostr(task.State));
    end;
end;


[nicke85]

This is the most exciting thing in pascal language now for me!
All newer version of Windows will used IDispatch interface in system dlls
Thank you a lot for this
Can't wait to come home to try this idea to..

Regards

[avra]

COM and ActiveX are not very popular in the fpc community.

They will be when the word spreads as tools get more and more in maturity. In industrial automation OPC is the standard way to connect to factory floor devices (www.opcfoundation.org, www.opcconnect.com/delphi.php). Since OPC DA is actually COM/DCOM, I am still bounded to Delphi for this. I hope this will change (especially since there are new guys in town like http://pascalscada.blogspot.com)  .

[ludob]

But I stick to my original Christmas holiday planning, TLB first, then H2pas fixes, and then who knows :-)

I dug up some old Delphi code that I wrote that used ITypeLib ITypeInfo (http://msdn.microsoft.com/en-us/library/ms221442%28v=VS.85%29.aspx) to get some typelib info. Advantage is that these interfaces read tlb but also extract type info from dll's and exe's (if present). A lot of the windows com objects don't come with tlb's The 2 task scheduling com servers (mstask.dll and taskschd.dll) are a nice example.
If you're interested, I can adapt that code to get all type info necessary to create a com binding.

[marcov]

But I stick to my original Christmas holiday planning, TLB first, then H2pas fixes, and then who knows :-)

I dug up some old Delphi code that I wrote that used ITypeLib ITypeInfo (http://msdn.microsoft.com/en-us/library/ms221442%28v=VS.85%29.aspx) to get some typelib info. Advantage is that these interfaces read tlb but also extract type info from dll's and exe's (if present). A lot of the windows com objects don't come with tlb's The 2 task scheduling com servers (mstask.dll and taskschd.dll) are a nice example.
If you're interested, I can adapt that code to get all type info necessary to create a com binding.

Yes, that is fine with me also.  There was a contributor (Matej ?? from Croatia) who contributed a lot to the early COM support working on something like that , but he stopped responding at some point.

Btw, did you see http://lazarus.freepascal.org/index.php/topic,9311.15/topicseen.html ?

[nicke85]

The for each enumeration with early binding doesn't need the EnumVariant unit anymore. The enumtasks sample becomes now:

Code: [Select]

uses TaskScheduler_TLB,activex;

procedure TForm1.EnumTasks2;
var TS:ITaskService;
  rootfolder:ITaskFolder;
  taskcollection:IRegisteredTaskCollection;
  task:IRegisteredTask;
  enum:IEnumVariant;
  item:variant;
begin
  TS:=CoTaskScheduler_.Create;
  TS.Connect(null,null,null,null);
  rootfolder:=TS.GetFolder('\');
  taskcollection:=rootfolder.GetTasks(0);
  enum:=taskcollection._NewEnum as IEnumVariant;
  enum.Reset;
  while enum.Next(1,item)=S_OK do
    begin
    task:=IDispatch(item) as IRegisteredTask;
    memo1.lines.add(task.Name+' '+ inttostr(task.State));
    end;
end;


for me easier is to use

Code: [Select]

for i:=1 to numberOfTasks do
  begin
     task:=TaskCollection.item[i] as IRegisteredTask;
     Memo1.Lines.Add(task.Name +' ' + IntToStr(task.State));
  end;

because code is more cleaner.But problem is how to get parmeters of task?
In API 1 is Interface ITask and there is a method GetParameters.What is with API 2?
I can't find anything about it..

[ludob]

for me easier is to use

Code: [Select]

for i:=1 to numberOfTasks do
  begin
     task:=TaskCollection.item[i] as IRegisteredTask;
     Memo1.Lines.Add(task.Name +' ' + IntToStr(task.State));
  end;

because code is more cleaner.But problem is how to get parmeters of task?
In API 1 is Interface ITask and there is a method GetParameters.What is with API 2?
I can't find anything about it..

As I wrote before, AFAIK not all enumerators start with 1. So be carefull with hard-coding ranges. Some enumerators also skip values. So as a minimum do a

Code: [Select]

if assigned(task) then ....

In API2 you use the inverse of what I did to create a task. To get the command line:

Code: [Select]

IExecAction(task.Definition.Actions[1]).PathTo get the arguments

Code: [Select]

IExecAction(task.Definition.Actions[1]).Arguments
This code violates what I wrote just before : index is hardcoded, no verification if there are no null pointers, etc. But it shows the chain of methods/properties to get to what you want. If you are making a task scheduling application make sure the intermediate values are properly verified.

[ludob]

Yes, that is fine with me also.  There was a contributor (Matej ?? from Croatia) who contributed a lot to the early COM support working on something like that , but he stopped responding at some point.

I'm progressing nicely on the importer. When working,  I'll create another thread to post the code instead of highjacking this one, or shall I create a new issue in the bugtracker?

Btw, did you see http://lazarus.freepascal.org/index.php/topic,9311.15/topicseen.html ?

I saw it this morning. When I published the demo on the mailinglist I got no reaction. Looks like the forum is a better place for posting this.