[APP][20Oct09]TICS-Installer-install plg in all cpr's[For all Plugins/Themes][RC3][6.5]

[Guest MichelDiamond]

Hey - I know - it works for each device - but I don't know, where in this Board are to find device-independent Developments - and here are the most friendly people and the most people who develop Themes or Plugins or Skins - for which is this extensions is from interest. In xda-devs you will also find TICS. But it's easier to download it here local:

ATPluginInstaller was a great idea-but we missed some things-and TICS can do it -especially installing a .plg in EACH .cpr!

TICS is short for Titanium Installator Controller Saver

- and here that's the "I" of it - it is absolutely independent from "C" and "S". They will come to another Time in some weeks or so.

This is only for people, who knows, what's a .cpr or a .plg - and it's the first beta.

TICS is upward-compatible to ATPluginInstaller in its Doing - but will do much more.

To introduce it, a little example to call TICS_installer, so you can already see, what's now possible:

TICS_installer.exe -addchange -plg:\\Internal Storage\\Sandbox\\default.plg -cpr:currentPortrait -silent

but also possible:

TICS_installer.exe -addchange -plg:\\Internal Storage\\Sandbox\\test.plg -cpr:\\Internal Storage\\Sandbox\\Titanium_480x640.cpr

and:

TICS_installer.exe -delete -plugin:Test -cpr:currentLandscape

[Direct Download of Setup.dll + scripts for Plugin-Developers: SetupDll_and_Mort.zip

Download TICS installer RC3:TICS_installer_ReleaseCandidate3.0.zip

Download TICS new installer RC3.1:TICS_installer_ReleaseCandidate3.1.zip

Now, you have seen the "specials" of TICS - but the first question of te Plugin-Makers will be: "what about the setup.dll?"

And that's very easy: ATPluginInstaller installed or uninstalled only the default.plg in Titanium_<res>.cpr - so it was possible.

TICS has to much options for this - and so you need another interface -but you already have it:

The Setup.dll from Mortscript calls "install.mscr" after installing a cab - and "uninstall.mscr" before uninstalling a cab.

The only MUST is: the Mortscript.exe, TitaniumRefresh.exe and the both mscr-Files and TICS_installer.exe must be installed in your main Directory of your Plugin.

But so we can also be asure, that each Plugin has now its right MortScript-Version - and everybody of us has a simple-to-use interface.

I will post an example for an install.mscr in Post #2

But now the Syntax of TICS-installer (and now it's changeable, after Release no more! It can only be expanded - but each Skinner, Themer, Plugin-Developer,... must rely on, that the Parameters from TICS_installer always be upward-compatible)

Usage:

Install/Change:

TICS_installer.exe -addchange -plg:<absolutePathToPlg> -cpr:currentPortrait|currentLandscape|<absolutePathToCpr> [-silent]

Uninstall:

TICS_installer.exe -delete -plugin:<PluginName> -cpr:currentPortrait|currentLandscape|<absolutePathToCpr> [-silent]

TICS has some more Parameters - but it would be too complex - it's indifferent at the moment

The Example in Post #2 will show the same thing as that was ATPluginInstaller did... almost... because "current" is the ative cpr - e.g. if you are using NeoTitanium - then TICS will install the .plg in NeoTitanium...

For whom it is needful to use TICS in future?

For the Users of course - no more problems to install Skins to whatever he uses in Titanium

For Developers of Plugins: their Plugins can now be used in each Titanium-Theme without adapting of the Theme-Makers - only depends from the ideas of the Skinners. Also they have a new interface after installing/before uninstalling a .cab - and Mortsript-knowledge would be enough

For Titanium-Theme-Makers: Now they can get help from the Skinners and the Plugin-Makers for a specific Plugin and no more for a whole cpr. Also the additional Parameters will help them, too

For Skinners: Much more possibilities to skin now :) Only by making that, what they can: Making great .plg's and Images!

TICS is free - like ATPluginInstaller - for each non-profit CHome-/Titanium-Plugin - so I'm only interested in enjoying this new possibilities of ech of you, too :D

Some important explanations:

- TICS_installer will only write in "ExtensibilityXML", "DefaultXML" and "Plugins" to CHome-Registry, if the Parameter for CPR is a "current..."-Parameter

- if there's no current Paramter TICS will create this Paramaters also for you - but then in "HKCU/Software/TICS" - with "newExtensibilityXML","new..."

- TICS uses "CPRFile" from CHome-Registry to identify the current CPR - it's automatically set by Windows-system because of ExtensibilityXML

- and you can use them by simple Registry-Copy in install.mscr or your Program like you need it for your Plugin

- You must set the <Position> in .plg - but if the Plugin already exists, then TICS ignores the Position in .plg - because it assumes, that the User has moved the Plugin to a better place for him (e.g. with CHome-Editor) - so it's more User-friendly

- TICS has definite Error-Messages and Number - which you can capture&handle while Installing a .plg - everything to find in "HKCU/Software/TICS"

- TICS recognizes your current resolution of your device - and only installs in the .cpr of this Resolution - no more in the other unused one

- Code optimization for faster speed & smaller size in .exe

- TICS makes a different between portrait and landscape in the .plg - s you have to call TICS twice if you want the same behaviour like ATPluginInstaller- but so you can also handle the different Sizes or can install different .plgs to Landscape and portrait... nice opportunity for Skinners B)

- it creates two temporary files direct in MainStorage "tempTitaniumLandscapeCpr.txt" and "tempTitaniumPortraitCpr.txt" which are the output files of - also a successful like a buggy call, too - of TICS - so you can handle it without need to copy something from Windows-Directory.

Of course will TICS change the current .cpr, too. And overwrite the temporary Files after next call of TICS

Everything else is already explained with ATPluginInstaller - but don't forget: CESetup.DLL = "setup.dll" in TICS! :

http://forum.xda-developers.com/showthread.php?t=509492

Only a summary of the new advantages of TICS:

- it's fast - written in C with MSDN - nothing else! Needs only 20ms for a complete operation on a .cpr

- You can handle EACH .cpr now :P The most importan of all

- .plg can be everywhere - you ca also save the .plg in Internal Storage together with the Images to copy full Skins to your Plugins

- Post-Installation-Hook - you can handle everything which you need for yor Plugin now while installing the cab (install.mscr)

- Pre-Deinstallation-Hook - you can handle everything which you need for yor Plugin now before uninstalling the cab (uninstall.mscr)

- in pre- and post- un/installation you can handle everything also before calling TICS and also after calling TICS

-Detailed Error Messages and Numbers to handle them

- Special support-parameters for JMLToday & TitaniumRSS and some other Plugins

- Silent-Mode - TICS can suppress the Error-Messages and only write them to Registry - and you can handle them on your own

- Change View of Titanium to TitaniumListView or BronzeListView (disabled in Beta)

- Makes differences between portrait and landscape - and so the possibiity to have abolutely different Skins in this directions

- only installs in your Resolution - so it's fast and need less storage in your Windows-Directory

- User-friendly (e.g. Position - see above)

- Let you handle the both last calls of TICS by providing everything about them in Registry.

Download attached

Please: It's a Beta: Before you try it - save your .cpr and the Values "ExtensibilityXML" and "Plugins" in Registry of CHome.

First File is Mortscript.exe (4.2-feel free to use,what you want) , TitaniumRefresh.exe, the setup.dll and an example for install.mscr and uninstall.mscr

Second File is TICS_installer.exe itself as zip

Please: Tell me, if you need more Parameters (I still have more :( ) and what would you want to have, too. At the moment I can change the parameters - after Release, they only can be expanded because of upward-compatibility.

And report any bug to me, if you see one - together with the Error Message or Registry-Settings of TICS in HKCU/Software/TICS

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

Changelog Beta2:

- Made a Fix to Compiler-Options - in the optimization it made something wrong sometimes in .exe

- Some Bugfixes because of Feedback (now it's stable with changing the Windows-CPR)

- Implemented this to JMLToday-cab and tested it: All works - and if this works, so we can be very sure, that it works for all Plugins instead of ATPluginInstaller

- added Parameters:

-- The Version-Number of TICS will alway be transmitted to Registry HKCU/Software/TICS:Version

-- "-nochangechomereg" : Independent from -current..., TICS_installer won't change the Registry of CHome - only create the key in HKCU/Software/CHome, which you can copy or use afterwards.

-- "-nochangecpr" : Independent from -current..., TICS won't write back the cpr-File to the original and will only provide the temp-File, which you can use by your install-script

-- "-isTICSSystemCall": This will be a reserved Parameter for the whole TICS-System - and you can never rely on,what it does-so never use it - it's only for "C" and "S" of TICS - and can change its behaviour

- Some small optimizations in code

- Tested it very hard: Works stable in all my Testcases

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

Changelog Release Candidate 3.0/3.1:

- Bufix of RC1.0 -some Plugins disappeared - now not anymore - works in all Plugins, which uses it (and that's a growing amount :D )

in 3.1:

-change view:TitaniumListView works now

Changelog Release Candidate 1:

- added "ForbiddenList"

If you have a special .cpr - and you want to prevent it temporary from changes by Plugin-Installations - you only have to add the name of the cpr to /HKCU/Software/TICS -> "ForbiddenList" - enclosed with semicolons,

e.g. ForbiddenList=";TitaniumRSS;;Specialcpr;"

Then TICS would also if "currentPortrait" or "currentLandscape" is set for cpr - only make the temporary Files for this cpr and also the temporary Registry-Entries - but wouldn't change the Titanium system.

- added check of ExtensibilityXML to get the correct cpr-Name

TICS uses normally "CPRFile" in CHome to identify the current cpr - but now it also looks into ExtensibilityXML - and if there is another cpr-Name - then TICS uses this CPR-Name and also sets "CPRFile" this name (it's really better for TitaniumSystem- that both settings are switched, also if you think, that ExtensibilityXML would be enough)

- added possibility to change a cpr to TitaniumListView / BronzeListview

with

TICS_installer.exe -change -view:TitaniumListView -cpr:currentPortrait

the current protrait cpr would be change to TitaniumListView - so that e.g. JMLPanex would also work with Titanium7Project. With:

TICS_installer.exe -change -view:BronzeListView -cpr:currentPortrait

it would be switched back

- increased speed - reduced filesice

you will see it :D .exe is now 35kb - and also for big cpr-Files very fast.

Thanx to Mort for providing the Setup.dll!!!

And AppStar for his great initial concept of ATPluginInstaller!!!

And I'm looking forward to new Themes & Skins, which are now much easier possible :D

Download TICS_installer RC3: TICS_installer_ReleaseCandidate3.0.zip

Download TICS_installer RC3.1: TICS_installer_ReleaseCandidate3.1.zip

Download Setup.dll+Mortscript-Calls for Plugin-Developers: SetupDll_and_Mort.zip

Cheers & Thanxs

Micha

Like my work? For a new device to test, motivation, better developing environment and especially coffee B) - to spend much more nights, you can donate a cup of coffee for me.

TICS_installer_beta2.zip

TICS_installer_ReleaseCandidate1.0.zip

Edited October 27, 2009 by MichelDiamond

[Guest MichelDiamond]

Example MortScript:

Here's the Mortscript, what would almost do thesame while installing a cab for a Titanium Pluing like ATPluginInstaller,

but with the difference: In the current (=active) CPR - it's also attached as example in Post #1 as download

...


###		  TICS_Installer  call portrait			   ###


plgPath=instPath\"test.plg"

callParameter="-addchange -plg:"&plgPath&" -cpr:currentPortrait"

message(callParameter)

RunWait(instPath\"TICS_installer.exe", callParameter)


###		  Handle here returned Error-Code: portrait		   ###


errorcode=RegRead("HKCU", "Software\TICS","ErrorNumber")

if (errorcode ne "0")

	messagetext="Portrait Installation failed: "& RegRead("HKCU", "Software\TICS","ErrorDescription")

	message(messagetext)

	exit

endif


###		  TICS_Installer  call landscape			   ###


plgPath=instPath\"test.plg"

callParameter="-addchange -plg:"&plgPath&" -cpr:currentLandscape"

RunWait(instPath\"TICS_installer.exe", callParameter)


###		  Handle here returned Error-Code: portrait		   ###


errorcode=RegRead("HKCU", "Software\TICS","ErrorNumber")

if (errorcode ne "0")

	messagetext="Landscape Installation failed: "& RegRead("HKCU", "Software\TICS","ErrorDescription")

	message(messagetext)

	exit

endif


###		  Code after call of TICS_Installer				 ###


Sleep(500)

RunWait(instPath\"CHomeRefresh.exe","")


message("finished")

exit

An example for uninstallation (parly) - it will uninstall your Plugin with the Name "Test" - replace it with the Name of your Plugin and it will work :)

...

RunWait(instPath\"TICS_installer.exe", "-delete -plugin:Test -cpr:currentLandscape")

RunWait(instPath\"TICS_installer.exe", "-delete -plugin:Test -cpr:currentPortrait")

...

Some other possible calls - e.g. also from C-/C++/-C#-/Whatever-Program:

// LPCWSTR ganzPar= L"-addchange -plg:\\Interner Speicher\\Sandbox\\test.plg -cpr:\\Interner Speicher\\Sandbox\\Titanium_480x640.cpr" ;

// LPCWSTR ganzPar = L"-addchange -plg:\\Interner Speicher\\Sandbox\\test.plg -cpr:currentPortrait";

// LPCWSTR ganzPar = L"-addchange -plg:\\Interner Speicher\\Sandbox\\test.plg -cpr:currentLandscape -isTICSSystemCall";

// LPCWSTR ganzPar = L"-delete -plugin:JMLToday -cpr:\\Interner Speicher\\Sandbox\\Titanium2_480x640.cpr";

// LPCWSTR ganzPar = L"-delete -plugin:Test -cpr:currentPortrait";

// LPCWSTR ganzPar = L"-delete -plugin:Test -cpr:currentLandscape";

// LPCWSTR ganzPar = L"-delete -plugin:Testplugin -cpr:all";

// LPCWSTR ganzPar = L"-delete -plugin:Testplugin -cpr:\\Interner Speicher\\Sandbox\\Titanium_480x640.cpr";

And here the Listings of the Registry-Keys in HKCU/Software/TICS :

callAction: Last kind of Call, e.g. addchange

callCPR: full-qualified path of CPR which should be changed

callOrgDefaultXML/callOrgExtXML/callOrgPlugins: Saves the DefaultXML/ExtensibilityXML/Plugins before Changing

callOverall: All Parameters which were given to TICS_installer

callPLG: full-qualified path of PLG which should be injected

callTypeCPR: direct or current

ErrorDescription: Long description of Error Message

ErrorNumber: Number of the Error

last...: The same as above for the Call before

new...: The changes of TICS in Registry - with "current" also in your Titanium - otherwise only here, so you can copy it after installation e.g. in install.mscr

Nice day 4 U

Micha

[Guest MichelDiamond]

<perhaps for later use>

Please feedback for Themes, Plugins, Skins,...

Micha

EDIT: JMLToday will soon released together with TICS - so that JMLToday can be direct installed in each Theme - independent from the .cpr - so the Skinners can make immediately .plg's for special Themes

[Guest sector]

Nice work Micha!

Thank you for this one :).

[Guest bga7x]

Ahhh Very Cool Thank you for this!!!!!

[Guest contable]

Welcome here at modaco, my friend !!! Thank you again for your great work and help.

Now we can leave ATPluginInstaller behind and look forward for creating new plugins, themes and skins with easier (and faster) installation.

I will include your app in one of my next releases.

Greetz

contable

[Guest Genix9]

Very nice indeed :)

I've been using Mortscript for the install/uninstall for while and it gives much better control than using the CEsetup.dll way.

Havn't had time to give it much thought but going to try it now. One thing I would like to suggest is having a cpr:currentBoth to avoid having to call TICS twice and read the .plg twice.

Edit: Just thought of something else;

- What about .plg positioning within the .cpr? -top or -bottom? This might also help with JMLpanex execution & caching speed? Maybe also something for JMLpanex, a parameter to point where to start looking for panex info for the current plugin?

- It definitely needs some sort of progress indicator to show that something is happening (even if it is really fast :D ), the like MS spinning dots.

Edited September 29, 2009 by Genix9

[Guest MichelDiamond]

Thanx for your Feedback :) Hope you can need it - and please tell me any Bugs, if there would be still somewhere, because it's also Release Candidate 1 and already hard tested and seems to work as it should.

@Genix9:

Yes - I understand your thoughts, I had the same as I developed it - but I saw, that very much standard themes are having a problem - because Landscape doesn't work very often, because some Plugins are only made for Portrait and so the whole Titanium was messed up by turning the device.

And the reason was a little bit in the way, how ATPluginInstaller handled it: It was indifferent for him, in which resolution it installs and in which "Turn-Mode".

TICS_installer installs only in one Resolution - the Resolution of your device. E.g. if you have WQVGA and the Parameter for cpr is "currentPortrait" - only the "Titanium_480x800.cpr" is changed. The others are completely useless - but formerly they got it too.

And also the Landscape & portrait - very often the .plg's are only for portrait - but that was for ATPluginInstaller indifferent - he installed it everywhere - and what was not found - no error message. And you activate the new Plugin - and it was disappeared or messed up the whole style.

Therefore I wanted to counteract this - because: How should react TICS, if it doesn't find the Landscape? Is it a error or not? And sometimes it could be one (if Titanium would be messed up, sometimes only the Plugin would disappear).

And so I thought, it would be the best way to make a difference - and with "-silent" you can suppress error messages from TICS - but you can handle each "forgotten" Landscape on your own by the Registry-Values, which are set by TICS.

And one word to "read the .plg twice" - it's a question of developing that it has to be read twice - also if there would be a currentBoth. ATPluginInstaller had to read it 10-12 times for one installation.

But: the read of the .plg is perhaps 1ms - the writing to .cpr is much more time - and for landscape and portrait - that's different files (e.g. Titanium_480x800.cpr and Titanium_800x480.cpr) - and I optimized TICS for a single call - so that one operations on a whole cpr takes only 20ms (with analysation, adding or changing the .plg) - a double call wouldn't be 40ms... I would estimate 100-150ms.

Let's see, if the awareness of the Developers is now helpful for the Theme-Makers - because it's better for the Theme-Makers with other .cpr's, that they can rely on, that each new .plg has the knowledge to provide both or has a possibility to handle it. They never run in this problem before - because they had to create their .cpr's on their own.

And also it's now possible to have different Themes in Landscape and Portrait :D

Later on we could expand it with "both" - is it ok?

Micha

[Guest MichelDiamond]

Oh - overseen the Edits:

Edit: Just thought of something else;

- What about .plg positioning within the .cpr? -top or -bottom? This might also help with JMLpanex execution & caching speed? Maybe also something for JMLpanex, a parameter to point where to start looking for panex info for the current plugin?

### The position will be ignored by TICS, if User has changed it and it was already there.

But a nice idea for additional parameters - indeed :) For rearranging - would perhaps interesting for the Theme-Makers

You perhaps seen - there's a third parameter, not only "-addchange" and "-delete" - there's a "-change" (without being called with a -plg, only for .cpr)

And this will be used for something like that, e.g. change from BronzeListView to TitaniumListView (-> JMLPanex works :D )

For JMLPanex-speed - since Version 2.00 the cache is an external file for each Plugin - and so there's no more difference, where the Plugin is in .cpr. Otherwise it would have been a good idea - but wouldn't have a effect - it's really fast in 2.00 because of the external files.

.cpr will only be read, if it was changed (new name, new date of file) and you call it for the first time with a button action.

- It definitely needs some sort of progress indicator to show that something is happening (even if it is really fast tongue.gif ), the like MS spinning dots.

### For 20ms it wouldn't be shown. But in Mortscript you could add it for all operations together - command "ShowWaitCursor" / "HideWaitCursor"

And don't forget - TICS... I=Installer... the "C"=Controller, which will also look for the integrity of Titanium and "S"ave it - for this, it could be from interest. But I want to update TitaniumRSS before and JMLToday 5.5 will come quite soon, too. And TICS_installer should remain independent form "C" and "S" - because - that will be User-Apps / Themer-Apps - no Skinner/Plugin-Devs-Apps.

[Guest Jumba]

Wow, I go away for a week and come back to this.

Awesome! Well done, Micha.

[Guest MichelDiamond]

Wow, I go away for a week and come back to this.

Awesome! Well done, Micha.

Welcome back my Friend :)

Now you can skin for much more Themes :D

(I append JMLToday 5.4 with TICS already - so everbody can use it in Bliss, Neo Titanium,...)

http://www.modaco.com/content/i9x0-omnia-h...-5-4-with-tics/

Edited September 29, 2009 by MichelDiamond

[Guest MichelDiamond]

OK - here's the 1st Release Candidate:

I added the wishes - I didn't changed the main features - so description is still the same to replace ATPluginInstaller with TICS_Installer - here are the adds of the First Release Candidate:

- added "ForbiddenList"

If you have a special .cpr - and you want to prevent it temporary from changes by Plugin-Installations - you only have to add the name of the cpr to /HKCU/Software/TICS -> "ForbiddenList" - enclosed with semicolons,

e.g. ForbiddenList=";TitaniumRSS;;Specialcpr;"

Then TICS would also if "currentPortrait" or "currentLandscape" is set for cpr - only make the temporary Files for this cpr and also the temporary Registry-Entries - but wouldn't change the Titanium system.

- added check of ExtensibilityXML to get the correct cpr-Name

TICS uses normally "CPRFile" in CHome to identify the current cpr - but now it also looks into ExtensibilityXML - and if there is another cpr-Name - then TICS uses this CPR-Name and also sets "CPRFile" this name (it's really better for TitaniumSystem- that both settings are switched, also if you think, that ExtensibilityXML would be enough)

- added possibility to change a cpr to TitaniumListView / BronzeListview

with

TICS_installer.exe -change -view:TitaniumListView -cpr:currentPortrait

the current protrait cpr would be change to TitaniumListView - so that e.g. JMLPanex would also work with Titanium7Project. With:

TICS_installer.exe -change -view:BronzeListView -cpr:currentPortrait

it would be switched back

- increased speed - reduced filesice

you will see it :) .exe is now 35kb - and also for big cpr-Files very fast.

I don't want to add new functionalities for 1.0 now - but this Beta-Thread will remain also after Release - to add this things to next versions.

But the main-calls to -addchange and -delete, which are in 1.0 - will remain forever in each next update - so only expansions ae possible after Release.

So you can be sure, tht all Plugins, which are installed by TICS - remain upward-compatible for the future.

(and in 2.0 we can talk about a currentAll, ok? :D )

Please tell me, if you'd see any bug in RC1 - but it was good tested and has almost no differences to Beta2 in the MainStream (but faster &smaller) - so it's not necessary to wait too long until RC1 will be 1st Release.

Please report anything, what you see in trial.

Thanx & have fun with making your Plugins installable for all Titanium-Themes

Micha

Edited October 7, 2009 by MichelDiamond

[Guest Genix9]

Any idea why I'm getting this error when running -addchange to update the default Portrait and Landscape .cprs?

"#200 cpr could not be copied to destination directory"

The default .cpr's are marked as read/write, and checking the TICS registry all the return values are correct.

Edit: Scrap that. Seems that on -delete the .cprs get set to ReadOnly for some reason.

Edited October 12, 2009 by Genix9

[Guest MichelDiamond]

Any idea why I'm getting this error when running -addchange to update the default Portrait and Landscape .cprs?

"#200 cpr could not be copied to destination directory"

The default .cpr's are marked as read/write, and checking the TICS registry all the return values are correct.

Edit: Scrap that. Seems that on -delete the .cprs get set to ReadOnly for some reason.

Some ROMs have write-protection on Windows--cpr

if you copy a cpr over your .cpr in Windows (you can rename the both temp--files in Root for example,and then vcopy them) , then it would work forever afterwards..

it's a really problem of some ROMs.

otherwise: just show me you calling mortscript.

Greetz

Micha

[Guest Genix9]

Some ROMs have write-protection on Windows--cpr

if you copy a cpr over your .cpr in Windows (you can rename the both temp--files in Root for example,and then vcopy them) , then it would work forever afterwards..

it's a really problem of some ROMs.

otherwise: just show me you calling mortscript.

Greetz

Micha

For the 1st install everything goes through fine. The install.mscr does what it should and TICS updates the .cprs ok.

Then run an un-install of the app and uninstall.mscr also works correctly.

Then run a 2nd install of exactly the same thing and it fails with the #200 error. This is the strange part, which is why it seems as if on -delete the .cpr attribs are being changed.

The correct vriables are being called and put thorugh to each command line - verified via TICS registry logs.

install.mscr

RunWait(InstallPath&"\TICS_installer.exe","-addchange -plg:"&InstallPath&"\plgFiles\default_analog.plg -cpr:currentPortrait")

 RunWait(InstallPath&"\TICS_installer.exe","-addchange -plg:"&InstallPath&"\plgFiles\default_analog.plg -cpr:currentLandscape")

uninstall.mscr

RunWait(InstallPath&"\TICS_installer.exe","-delete -plugin:GenToday -cpr:currentPortrait")

 RunWait(InstallPath&"\TICS_installer.exe","-delete -plugin:GenToday -cpr:currentLandscape")

[Guest MichelDiamond]

For the 1st install everything goes through fine. The install.mscr does what it should and TICS updates the .cprs ok.

Then run an un-install of the app and uninstall.mscr also works correctly.

Then run a 2nd install of exactly the same thing and it fails with the #200 error. This is the strange part, which is why it seems as if on -delete the .cpr attribs are being changed.

The correct vriables are being called and put thorugh to each command line - verified via TICS registry logs.

install.mscr

RunWait(InstallPath&"\TICS_installer.exe","-addchange -plg:"&InstallPath&"\plgFiles\default_analog.plg -cpr:currentPortrait")

 RunWait(InstallPath&"\TICS_installer.exe","-addchange -plg:"&InstallPath&"\plgFiles\default_analog.plg -cpr:currentLandscape")

uninstall.mscr

RunWait(InstallPath&"\TICS_installer.exe","-delete -plugin:GenToday -cpr:currentPortrait")

 RunWait(InstallPath&"\TICS_installer.exe","-delete -plugin:GenToday -cpr:currentLandscape")

Hi, I've looked into code, if there would be other possibilities for this messages - but I set #200 only, when File is copied from root of Main Storage to Windows. Indifferent if you use -addchange or -delete. Perhaps the root directory is the problem - perhaps there is set by system a write-protection. I used it because there are the most rights... mmh. But there's also a solution, which you can try - if Destination .cpr is write-protected - you now have Mortscript as Interface before the Delete-Call - you know from MortScript "SetFileAttribute" and "SetFileAttribs" ? Could you try the disable the write-protection in uninstall.mscr? I'm glad to have now this possibilities to be able to make an operation before each call while installing a .cab. ( e.g. I check if some needed .cab's are installed and can change my .plg which is to be installed by default because of this) Also - there are some Mortscript-"Traps" - which I also went into :) : If you call Mortscript cascaded with CallScript - all Variable are used global - and there are really strange side-effects. And please have also a look, what the system could do between install and uninstall - perhaps a 3rd-Party-program is setting this write-protection. I hope there will be help from me soon - when I developed TICS-Controller. Please feedback after trying SetFileAttr... Greetz Micha EDIT: One Remark - it's not good to use

InstallPath&"\TICS_installer.exe"...

it's better for each Backslash-separation:

InstallPath\"TICS_installer.exe"...

So you can be sure, that there is exactly one backslash. I sometimes forget it, too - until a file isn't found :(

Edited October 13, 2009 by MichelDiamond

[Guest Genix9]

...

Perhaps the root directory is the problem - perhaps there is set by system a write-protection. I used it because there are the most rights... mmh.

But there's also a solution, which you can try - if Destination .cpr is write-protected - you now have Mortscript as Interface before the Delete-Call - you know from MortScript "SetFileAttribute" and "SetFileAttribs" ? Could you try the disable the write-protection in uninstall.mscr? I'm glad to have now this possibilities to be able to make an operation before each call while installing a .cab.

EDIT: One Remark - it's not good to use

InstallPath&"\TICS_installer.exe"...

it's better for each Backslash-separation:

InstallPath\"TICS_installer.exe"...

So you can be sure, that there is exactly one backslash. I sometimes forget it, too - until a file isn't found :(

Yep, I'm using SetFileAttribute now to get around the problem, so that works ok. Just weird that it happens. I used ATPluginInstaller previously in the the same calls, and the write protect issue never occured. Strange. :)

Thanks for the heads-up on the backslash. Makes good sense ;)

[Guest MichelDiamond]

Yep, I'm using SetFileAttribute now to get around the problem, so that works ok. Just weird that it happens. I used ATPluginInstaller previously in the the same calls, and the write protect issue never occured. Strange. :)

Thanks for the heads-up on the backslash. Makes good sense :(

Cool that this works - in ATPluginInstaller there was the same problem sometimes (look into the thread of xda-devs) - but I never saw the source code, so I don't know which Function he used from MSDN (Perhaps the .net-equivalent)

But there will be alternatives later on perhaps - to call some other functions - especially "move with overwrite". Let's see -I want to see some specifications of WinMo 6.5 at first.

Would you tell me, if you made your Plugin with TICS - I want to make a Thread next or overnext weekto collect, which Plugins are running with TICS, so that the people with Non-Standard-Theme knows, what they could install direct?

Greetz

Micha

[Guest MichelDiamond]

Hey - Board disappeared after my Posing and Posting was away...

So at first - I released TICS_installer RC2.0

In seldom cases (Positions, WinMo-Builds) Plugins could disappear, new version fixes this seldom bug.

Now I'm short of time - so Link at the moment in devs:

Download new TICS_installer RC2: *ext. Link*

Greetz

Micha

[Guest MichelDiamond]

Sorry Guys, I've uploaded wrong version with RC2.0

So - I renamed tested RC2 to RC3.0 - upload in Post #1 now

Micha

[Guest contable]

Sorry Guys, I've uploaded wrong version with RC2.0

So - I renamed tested RC2 to RC3.0 - upload in Post #1 now

Micha

Hi Micha !

How are you ? Actually I´m very busy so I couldn´t write you. I will add your TICS in my AppLauncher plugin for standard titanium.

Once again great work !!!

Greetz

contable

[Guest Genix9]

Sorry Guys, I've uploaded wrong version with RC2.0

So - I renamed tested RC2 to RC3.0 - upload in Post #1 now

Micha

Aewsome, will test right away :)

[Guest MichelDiamond]

And? All ok?

I have added Download of TICS RC3.1 - it has no change against RC3.0 for Plugin-Installation - but -change: view:TitaniumListView works now

I removed RC1.0 and Beta2 from Post #1 - because they are old and 1.0 had a bug (never use it again - I recommend 3.1 of course, ut if you already use 3.0 for your Plugin, you can wait until you want to update)

It runs fine with a growing amout of Titanium-Plugins so I think it's all o.k.

Please feedback wishes or any things you mention

Greetz

Micha

[Guest Genix9]

Hey Micha, sorry for being so quiet, work stuff and all :D

The 3.0 version works well. It does strange things on the WM6.5 emulator like resetting the .cpr attributes, but I think that's more to do with the emulator than TICS since on a real device everything works fine (maybe there's a newer version, I need to check).

There are a couple of requests I do have;

1. In most .plg files people insert header text to ID their plugin like <!-- MyPlugin --> for example. When TICS installs the .plg this line is transferred to the .cpr fine. But, when using -delete or -addchange this header text is left behind (same as ATPLugin does). So a bunch on install/uninstalls (especially when testing) leaves a lot of these junk headers in the .cpr.

Can you check the code to remove the header text as well when doing any .cpr updates?

2. How is TICS handling spaces and tabs in .plg's? I have formatted my .plg quite well (makes it easier for readability and debugging/changing), but when it goes to the .cpr it ends up qute a mess. It works obviously, but reading it is difficult. I'd just like to find out if TICS would prefer spaces or tabs to format the .plg?

[Guest contable]

Hey Micha, sorry for being so quiet, work stuff and all :D

The 3.0 version works well. It does strange things on the WM6.5 emulator like resetting the .cpr attributes, but I think that's more to do with the emulator than TICS since on a real device everything works fine (maybe there's a newer version, I need to check).

There are a couple of requests I do have;

1. In most .plg files people insert header text to ID their plugin like <!-- MyPlugin --> for example. When TICS installs the .plg this line is transferred to the .cpr fine. But, when using -delete or -addchange this header text is left behind (same as ATPLugin does). So a bunch on install/uninstalls (especially when testing) leaves a lot of these junk headers in the .cpr.

Can you check the code to remove the header text as well when doing any .cpr updates?

.........

@Genix9: While developing my new plugins I noticed that, too. If you uninstall a plugin TICS leaves some rows of these junk headers in the cpr. All in all it´s working excellent. Compared with ATPluginInstaller it´s a real improvement. The only thing I don´t like is that I´ve to copy everytime the mortscript.exe to each plugin folder, so the plugins need more space on the device. I thought about removing the mortscript.exe after installing the plugin, but then the uninstall.mscr doesn´t work, because the setup.dll is using the mortscript.exe in the plugin folder. Maybe Micha can solve this small problems.

@Micha: The incredible Evidence_I cooked in my plugins with TICS !!! Check out the screenshots in my thread. Thank you again for that great tool, my friend !

Edited October 30, 2009 by contable