[SOLVED] Task Schreduling in Windows 7 (API ver. 2) ??
lazarus / 34-Windows

----------------------------------------------------------------------
nicke85 · 2011-12-15 21:58

I have wrapper for API 1 in windows xp and in Windows vista and 7 is
API 2.
How I can setup and managing tasks in task schreduler in Windows 7?
Any idea?

Regards

----------------------------------------------------------------------
ludob · 2011-12-16 10:19

There are several ways of doing this.
-VB style: create com object and use late binding
-C++ style: define interfaces and use early binding
-mixed: create XML file and load it using one of the above methods.
-execute the Schtasks.exe command line tool
The easiest is probably the 4th option.

What method is your api 1 wrapper using now?

----------------------------------------------------------------------
nicke85 · 2011-12-16 15:17

Hi ludob,I use mstasks.pas from JEDI-library it is wrapper for API 1
and there are methods.
Well if i could make some process to get enumerated type with
Schtasks.exe it would be great.
But with SchTasks i can create,modify and when want to delete task
than there is a confirmation for that.How to make it to be an
automated process without confirmation?

----------------------------------------------------------------------
ludob · 2011-12-16 17:42

Then probably the VB style late binding is what you need. This sounds
difficult but is rather simple once you get the basics. Nothing better
than an example to show how it works   I translated the VBscript
sample you find here http://msdn.microsoft.com/en-
us/library/windows/desktop/aa383665%28v=VS.85%29.aspx to pascal
(tested on win7 64 bit):
Code: [Select]uses comobj;

procedure TForm1.TimeTrigger;
var
 
service,rootfolder,taskdefinition,reginfo,principal,settings,triggers,
  trigger,action_:Olevariant;
begin
  service:=CreateOleObject('Schedule.Service');
  service.connect;
  rootfolder:=service.GetFolder(Olevariant('\'));
  taskdefinition:=service.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:=olevariant('2011-12-16T18:30:00+01:00');
  trigger.EndBoundary:=olevariant('2011-12-16T18:40:00+01:00');
  trigger.ExecutionTimeLimit:=olevariant('PT5M');
  trigger.Id:=olevariant('TimeTriggerId');
  trigger.Enabled:=true;
  action_:=taskdefinition.Actions.Create(0);
  action_.Path:=olevariant('c:\Windows\system32\notepad.exe');
  rootfolder.RegisterTaskDefinition(olevariant('Test TimeTrigger'),
         taskdefinition,6,NULL,NULL , 3);
end;


This launched notepad at 18:30 utc+1 today. These are all reference
counted objects. No need to clean up when leaving.

Note that you need a recent compiler since a lot of changes where made
in the compilers com support. I recommend 2.6.0 rc1.

----------------------------------------------------------------------
nicke85 · 2011-12-16 18:49

You are right ludob this really sounds difficult but it is maybe
solution for me since i don't programming in VB for a few years now
but know the basics what are you talking about.
I really don't know how you figured this out?
Also did't know for comobj library in fpc this is really amazing news
for me.
Is somewhere exist some more information about COM and ole classes in
fpc?
Thank you a lot for an example.
I'll try to figure this way of COM programing.

----------------------------------------------------------------------
ludob · 2011-12-16 19:30

QuoteIs somewhere exist some more information about COM and ole
classes in fpc?Com is a vast subject. There are a few articles around
about delphi and ole automation that you can use as an introduction to
this late binding COM method.
Fe. http://delphi.about.com/cs/adptips2003/a/bltip0303_5.htm,
http://edn.embarcadero.com/article/10126 
Fpc misses some tools that are included with Delphi but has the
necessary compiler support to work with COM. An important difference
is that in fpc you need to use OleVariant for COM instead of variant.
There are small differences between the 2 which affect marshaling.
Variant has some OLE incompatible subtypes.

----------------------------------------------------------------------
nicke85 · 2011-12-17 23:28

Here is a problem Object Pascal doesn't have for-each loop so i can't
pass values from set from olevariant or variant type.
I tried to use late binding from this page
http://msdn.microsoft.com/en-
us/library/windows/desktop/aa446865%28v=VS.85%29.aspx
Code: [Select]procedure TForm1.btn1Click(Sender: TObject);
var
  service,rootFolder,numberOfTasks,TaskCollection,MyTask :OleVariant;
  i:Integer;
begin
  service := CreateOleObject('Schedule.Service');
  service.Connect;
  rootFolder := service.GetFolder(OleVariant('\'));
  TaskCollection := rootFolder.GetTasks(0);
  numberOfTasks := TaskCollection.Count;
  if numberOfTasks = 0 then ShowMessage('there is nothing') else
  begin
    For i:=0 to numberOfTasks - 1 do
        ShowMessage('where are tasks im not for each in loop');
  end;
end;

Is it posible to enumerate values on some another way?

My logic is to make
Code: [Select]For MyTask in TaskCollection do
        ShowMessage('test');
but it is not posible anyway on variant

----------------------------------------------------------------------
nicke85 · 2011-12-18 09:16

Solved!!!
Here is referenced loop
Code: [Select] for i:= 1 to numberOfTasks do
      ShowMessage(TaskCollection.item[i].name);

Thanks again ludob

----------------------------------------------------------------------
ludob · 2011-12-18 11:45

Code: [Select] for i:= 1 to numberOfTasks do
      ShowMessage(TaskCollection.item[i].name);
That is indeed a workaround. I'm not sure that all collections are 1
based, though.
The better way is to use the IEnumVariant interface. I have ported
TEnumVariant from comlib.pas
(http://www.techvanguards.com/com/resources/downloads.asp) to fpc.
Attached is the file.
To use it:
Code: [Select]uses enumvariant;
...
var task olevariant;
...
with TEnumVariant.Create(taskcollection) do
  try
    while ForEach(task) do
       ShowMessage(task.name);
  finally
    free;
  end;

----------------------------------------------------------------------
nicke85 · 2011-12-18 13:01

Thanks,
Curently now I work with pure OleObject from your example.
I have edited taskschd.dll file and found all methods related for
TaskSchreduler class.It is performed for C++ but as you say it can be
used in late binding like in VB style.

If I make reference:
Code: [Select]registeredTask := TaskFolderCollection.Item[3];
Then can use
Code: [Select]ShowMessage(registeredTask.path); // to see path
registeredTask.Run(NULL); // to run task
rootFolder.DeleteTask(registeredTask.Name, 0); // to delete task

And this is a curently working code,I try to figure enumerated tasks
Code: [Select]for i := 1 to numberOfTasks do
      begin
       Memo1.Lines.Add(TaskCollection.Item[i].Name);
       Memo1.Lines.Add(TaskCollection.Item[i].NextRunTime);
..etc..

The Idea is to set tasks into stringgrid and then to make reference
between rootfolder enumerated tasks and stringgrid,to can use task
index selection for current task and modify task.

I think that it is more simpler for me than interfaced object.
If you have some more sugestion go agead and tell I would like to
figure out interface method
but it early binding style

----------------------------------------------------------------------
ludob · 2011-12-18 14:04

The enumvariant unit works also with late binding. The code snippet
Code: [Select]with TEnumVariant.Create(taskcollection) do
  try
    while ForEach(task) do
       ShowMessage(task.name);
  finally
    free;
  end;is a replacement for
Code: [Select]  numberOfTasks := TaskCollection.Count;
  for i:= 1 to numberOfTasks do
      ShowMessage(TaskCollection.item[i].name);
Early binding is too complex for the program you want to create. Late
binding has quite some overhead but for this type of applications it
really doesn't matter (unless you want to create and delete a few
hundred tasks per minute   )

----------------------------------------------------------------------
nicke85 · 2011-12-18 14:43

You are right,i didn't figured loop.
So the next question is,can I use late binding to make
universal,platform independent code for XP and Win7 at the same time?
I can't find nothing about API 1 classes on the internet there is only
early binding and C++ wrapper on MSDN site.
Seems that API 2 is more eaisier for manipulate than API 1.

Regards

----------------------------------------------------------------------
ludob · 2011-12-18 15:28

mstask is a COM object but not dual interfaced. It is missing the
IDispatch interface needed to do late binding. Only early binding is
possible. There are some tricks to access mstasks with late binding
through WMI but that would be more difficult than using the wrapper
for API 1.0. It wouldn't give you a "universal" solution neither.
Looks like you will have to duplicate the code for the 2 api versions.

----------------------------------------------------------------------
marcov · 2011-12-18 18:04

Quote from: ludob on December 18, 2011, 04:28:03 pmmstask is a COM
object but not dual interfaced. It is missing the IDispatch interface
needed to do late binding. Only early binding is possible. There are
some tricks to access mstasks with late binding through WMI but that
would be more difficult than using the wrapper for API 1.0. It
wouldn't give you a "universal" solution neither.
Looks like you will have to duplicate the code for the 2 api versions.

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

----------------------------------------------------------------------
ludob · 2011-12-18 18:17

QuoteI 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.

----------------------------------------------------------------------
nicke85 · 2011-12-18 18:31

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 · 2011-12-18 18:42

Quote from: ludob on December 18, 2011, 07:17:14 pmQuoteI 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 · 2011-12-18 19:13

QuoteI 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 · 2011-12-18 20:59

Quote from: ludob on December 18, 2011, 08:13:32 pmQuoteI 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.

QuoteIs 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)

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

It's only starting.

QuoteDelphi 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.

QuoteThe 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 · 2011-12-19 07:21

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.
Quote1) 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.
Quote2) 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.
Quote4) 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 · 2011-12-19 09:33

Quote from: ludob on December 19, 2011, 08:21:40 amCode: [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.

QuoteQuote1) 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 ;-)

QuoteQuote2) 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.

QuoteQuote4) 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.

QuoteXPCOM 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.

QuoteCode: [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 · 2011-12-19 16:01

Quote from: nicke85 on December 18, 2011, 07:31:45 pmyou 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 · 2011-12-19 16:21

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 · 2011-12-19 21:19

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 · 2011-12-20 08:08

Quote from: ludob on December 18, 2011, 08:13:32 pmCOM 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 · 2011-12-20 08:21

Quote from: marcov on December 19, 2011, 10:33:57 amBut 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 · 2011-12-20 12:20

Quote from: ludob on December 20, 2011, 09:21:02 amQuote from: marcov
on December 19, 2011, 10:33:57 amBut 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 · 2011-12-20 13:01

Quote from: ludob on December 19, 2011, 05:21:55 pmThe 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 · 2011-12-20 13:51

Quote from: nicke85 on December 20, 2011, 02:01:17 pmfor 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 · 2011-12-20 14:06

Quote from: marcov on December 20, 2011, 01:20:14 pmYes, 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?
Quote from: marcov on December 20, 2011, 01:20:14 pmBtw, 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.

----------------------------------------------------------------------
marcov · 2011-12-20 20:25

Quote from: ludob on December 20, 2011, 03:06:56 pmQuote from: marcov
on December 20, 2011, 01:20:14 pmYes, 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?

For me Mantis is easier. FPC project though :_)

----------------------------------------------------------------------
nicke85 · 2011-12-23 10:18

I work with olevariant,and need to pass datetime from example
TDateTimePicker or some other source into my method which pass that
value to olevariant.
Does I need to specify format of datetime to some specific format for
olevariant?

----------------------------------------------------------------------
ludob · 2011-12-23 10:51

Quote from: nicke85 on December 23, 2011, 11:18:58 amI work with
olevariant,and need to pass datetime from example TDateTimePicker or
some other source into my method which pass that value to olevariant.
Does I need to specify format of datetime to some specific format for
olevariant?
Just assign TDateTime to OleVariant.

----------------------------------------------------------------------
nicke85 · 2011-12-23 11:25

QuoteJust assign TDateTime to OleVariant.
I doesn't work.I found solution sorry for my fast question.
Datetime must be formated like YYYY-MM-DDTHH:MM:SS(+-)HH:MM
so i wrote Function to convert TDateTimePiscker or any datetime class
to right format because
olevariant can handle string and pass to right format

Code: [Select]function TForm1.SetTime(DateTimePicker:
TDateTimePicker): string;
var
date: ShortString;
time: ShortString;
begin
 DateSeparator:='-';
 date:=FormatDateTime('yyyy/mm/dd', DateTimePicker.Date);
 time:=FormatDateTime('HH:MM:SS',DateTimePicker.Time);
 Result:=date+'T'+time+'+01:00';
end;
end.

----------------------------------------------------------------------
ludob · 2011-12-23 15:04

QuoteI doesn't work.I guess you are trying to set StartBoundary or
EndBoundary. These are defined as a WideString with a particular
format and no "automagic" OLEVariant conversion will work. There are
properties such as IRegisteredTask.NextRunTime that use a TDateTime
compatible format.
QuoteResult:=date+'T'+time+'+01:00';Task Scheduling api uses UTC and
+1:00 is CET winter time. You'll need to adapt your routine to local
timezone and day savings time.

----------------------------------------------------------------------
nicke85 · 2011-12-23 19:39

Quote from: ludob on December 23, 2011, 04:04:21 pm
I guess you are trying to set StartBoundary or EndBoundary. These are
defined as a WideString with a particular format and no "automagic"
OLEVariant conversion will work. There are properties such as
IRegisteredTask.NextRunTime that use a TDateTime compatible format.Yes
Start and End DateTime.DateTimePicker is only testing for format
input.
Well function from above done the job.I can pass ShortString to
olevariant..

Regards