Release posted and source code in Codeplex is up to date.
I will be testing the release over the next few days.
New features include:
All c++ Explorer extensions - no more loading the CLR into the shell
Multi server support - Have working folders for Codeplex and local TF Servers
Paged history - get revision logs in smaller chunks
History through branches - see history belonging to originating branches
More to follow...
Sunday, 19 October 2008
Saturday, 4 October 2008
By 'eck, they don't half make it difficult sometimes...
Progress has been slow, between two many DIY jobs and to much work at work, Lizard 0.3 is proving a bit hard to get out. One of the reasons is that I'm not much of a c++ programmer, or rather I'm not use to unravelling c++ documentation/examples on the internet.
What follows will probably be of little interest to anyone except those from c# (or VB, or Delphi etc) background who are trying to find their feet with c++ and COM.
I wanted to read the location of the Lizard meta-data folder from the registry (it's been hard-coded up till now). I quickly found I needed the CRegKey.Open and CRegKey.QueryStringValue methods, but wanted to see some examples to see how they really worked. After spending way too much time reading 163 different variations on a theme, I wrote my own based on this article from the Geak Technologies web site (thanks chaps, who ever you are). The problem I have with c++ examples and tutorials is they hardly ever show all the #includes you need or which libraries you need to add to the linker, and of course, it being c++, always disagree with what sort of string to use. Always use CString! std::string is superior! Real programmers use... etc etc. Some forums had posters getting quite angry that someone suggested the 'wrong' sort of strings for this or that, but I'm guessing from the multitude of opinions that there isn't just one (or even two or three) right way.
My extensions use CComBSTR a lot, this will probably make a lot of people purple with rage, but they seem to be the easiest if you want to interact with COM objects and are using ATL.
Any way, for any one who got here because they searched for 'c++ Registry Access, Key, Path'
here is some code:
#include "stdafx.h"
#include
using namespace ATL;
#include "RegistryAccess.h"
CComBSTR GetRegistryKeyValue(CComBSTR regKey, CComBSTR valueName)
{
CRegKey key;
CComBSTR value="";
long nError = key.Open(HKEY_CURRENT_USER, regKey.m_str, KEY_READ);
if(nError == ERROR_SUCCESS)
{
DWORD dwBufferSize = MAX_PATH;
LPTSTR v = new TCHAR[MAX_PATH];
key.QueryStringValue(valueName.m_str, v , &dwBufferSize );
value.Append(v,dwBufferSize);
}
return value;
}
If you're writing an ATL based project then #include might well already be in your 'stdafx.h' but I wanted to include it here because it defines CComBSTR and CRegKey. This code works but really didn't warrant two hours of my life.
Yeah, I know I should get a good book and learn this stuff properly, know what the relationship between a LPCTSTR and a *PCH is, and memorise every typedef in every .h file in the c++ sdk, but that is for another day.
Let the flaming begin!
What follows will probably be of little interest to anyone except those from c# (or VB, or Delphi etc) background who are trying to find their feet with c++ and COM.
I wanted to read the location of the Lizard meta-data folder from the registry (it's been hard-coded up till now). I quickly found I needed the CRegKey.Open and CRegKey.QueryStringValue methods, but wanted to see some examples to see how they really worked. After spending way too much time reading 163 different variations on a theme, I wrote my own based on this article from the Geak Technologies web site (thanks chaps, who ever you are). The problem I have with c++ examples and tutorials is they hardly ever show all the #includes you need or which libraries you need to add to the linker, and of course, it being c++, always disagree with what sort of string to use. Always use CString! std::string is superior! Real programmers use... etc etc. Some forums had posters getting quite angry that someone suggested the 'wrong' sort of strings for this or that, but I'm guessing from the multitude of opinions that there isn't just one (or even two or three) right way.
My extensions use CComBSTR a lot, this will probably make a lot of people purple with rage, but they seem to be the easiest if you want to interact with COM objects and are using ATL.
Any way, for any one who got here because they searched for 'c++ Registry Access, Key, Path'
here is some code:
#include "stdafx.h"
#include
using namespace ATL;
#include "RegistryAccess.h"
CComBSTR GetRegistryKeyValue(CComBSTR regKey, CComBSTR valueName)
{
CRegKey key;
CComBSTR value="";
long nError = key.Open(HKEY_CURRENT_USER, regKey.m_str, KEY_READ);
if(nError == ERROR_SUCCESS)
{
DWORD dwBufferSize = MAX_PATH;
LPTSTR v = new TCHAR[MAX_PATH];
key.QueryStringValue(valueName.m_str, v , &dwBufferSize );
value.Append(v,dwBufferSize);
}
return value;
}
If you're writing an ATL based project then #include
Yeah, I know I should get a good book and learn this stuff properly, know what the relationship between a LPCTSTR and a *PCH is, and memorise every typedef in every .h file in the c++ sdk, but that is for another day.
Let the flaming begin!
Sunday, 14 September 2008
TFS installation nightmares
I was running my test TFS server on an eval version of SQL server. I now have a full version, the eval ran out so I thought let's upgrade! Ha!
You can upgrade SQL server versions, but only if the original service is running. No good if your eval has expired! Started installing everything from new, but getting silly errors somewhere around the SPS set up. This is about the 4th time I've installed TFS and it's still a pig.
Meanwhile I thought it was about time I used CodePlex's TFS server with LizardTF to see how it works. There is now source code available from:
http://www.codeplex.com/lizardtf/SourceControl/ListDownloadableCommits.aspx
It is very bleeding edge at the moment as I settle in the new c++ shell extensions.
Playing with my source code in CodePlex made me make some optimisation work a high priority, and I also got a bit annoyed with the '_ltf' folders, a system copied from TortoiseSVNs '.svn' folders. I have now moved the meta data to it's own 'special' folder, thus keeping the actual working folders clear of Lizard meta data, allowing easier zipping, browsing etc etc. The metadata for each working folder is now stored in a special folder (configurable) using a hash of the working foldername to flatten the hierarchy. I have just written (borrowed from MSDN MD5 sample, and another Base64 sample) a c++ folder path hasher, that miraculously matches the one I wrote in c# using System.Security.Cryptography.MD5CryptoServiceProvider and Convert.ToBase64. This allows the shell extensions to keep quiet unless metadata exists, leaving performance for browsing non-TFS folders unchanged. Browsing TFS working folders over the internet to CodePlex is a little slow (4-6 seconds for a folder with 30-40 files in it) but it is usable. I'll be thinking of how to allow customising the functionality for slow connections.
I think I've got the extensions pretty stable now, so will be looking to get a build out soon, Alpha 0.3.1, I guess.
May be then I can get on with some of the functionality I've meaning to do for over a year now....
You can upgrade SQL server versions, but only if the original service is running. No good if your eval has expired! Started installing everything from new, but getting silly errors somewhere around the SPS set up. This is about the 4th time I've installed TFS and it's still a pig.
Meanwhile I thought it was about time I used CodePlex's TFS server with LizardTF to see how it works. There is now source code available from:
http://www.codeplex.com/lizardtf/SourceControl/ListDownloadableCommits.aspx
It is very bleeding edge at the moment as I settle in the new c++ shell extensions.
Playing with my source code in CodePlex made me make some optimisation work a high priority, and I also got a bit annoyed with the '_ltf' folders, a system copied from TortoiseSVNs '.svn' folders. I have now moved the meta data to it's own 'special' folder, thus keeping the actual working folders clear of Lizard meta data, allowing easier zipping, browsing etc etc. The metadata for each working folder is now stored in a special folder (configurable) using a hash of the working foldername to flatten the hierarchy. I have just written (borrowed from MSDN MD5 sample, and another Base64 sample) a c++ folder path hasher, that miraculously matches the one I wrote in c# using System.Security.Cryptography.MD5CryptoServiceProvider and Convert.ToBase64. This allows the shell extensions to keep quiet unless metadata exists, leaving performance for browsing non-TFS folders unchanged. Browsing TFS working folders over the internet to CodePlex is a little slow (4-6 seconds for a folder with 30-40 files in it) but it is usable. I'll be thinking of how to allow customising the functionality for slow connections.
I think I've got the extensions pretty stable now, so will be looking to get a build out soon, Alpha 0.3.1, I guess.
May be then I can get on with some of the functionality I've meaning to do for over a year now....
Monday, 25 August 2008
Coming together again...
I've had a break, a week in California and a week on Cape Cod, I'm back in England, I've taken my study apart, laid a new floor, and put it back together again.
I've just picked up the pieces of re-writing the explorer shell extensions in c++ (so that explorer won't load the .Net run-times and get itself into trouble). I hope Microsoft support .Net shell extension in Windows 7.
A break did me some good, and things have progressed well since.
The new extensions are working well, all the icon overlays are in place using TortoiseOverlays. I know I said they were done in July, but I was getting a bit ahead of myself. The codes much neater now, and client/server operations minimised. The only issue I have at the moment is that the 'Normal' overlay doesn't appear, when I attach the same Lizard handler to a different TortoiseOverlay handler all works fine, so I think there's either something up with the TortoiseOverlays code (unlikely) or something up with the config (more likely) but it all looks right, and is the same for all the working ones.
I've got to optimise the item data requests for the additional list view columns, but the techniques used for overlays will work again here, so its just implementation. I'm going to leave the property page out for now to try a get a build out. I'm not entirely happen about the build process with the c++ project. For some reason regsvr32 always fails for the output dll, so COM registration is manual. I'll probably post the source, a good build and a .reg file initially and leave it to those who want to to create their own build process.
I'm away next weekend, but realistically I'm hoping to get something published but mid september. I'm also planning to provide support for assigning different TFS servers to working folders and up loading all the source to the Codeplex TFS server and testing Lizard against that.
After that, back to features list, and on to a Beta release!
I've just picked up the pieces of re-writing the explorer shell extensions in c++ (so that explorer won't load the .Net run-times and get itself into trouble). I hope Microsoft support .Net shell extension in Windows 7.
A break did me some good, and things have progressed well since.
The new extensions are working well, all the icon overlays are in place using TortoiseOverlays. I know I said they were done in July, but I was getting a bit ahead of myself. The codes much neater now, and client/server operations minimised. The only issue I have at the moment is that the 'Normal' overlay doesn't appear, when I attach the same Lizard handler to a different TortoiseOverlay handler all works fine, so I think there's either something up with the TortoiseOverlays code (unlikely) or something up with the config (more likely) but it all looks right, and is the same for all the working ones.
I've got to optimise the item data requests for the additional list view columns, but the techniques used for overlays will work again here, so its just implementation. I'm going to leave the property page out for now to try a get a build out. I'm not entirely happen about the build process with the c++ project. For some reason regsvr32 always fails for the output dll, so COM registration is manual. I'll probably post the source, a good build and a .reg file initially and leave it to those who want to to create their own build process.
I'm away next weekend, but realistically I'm hoping to get something published but mid september. I'm also planning to provide support for assigning different TFS servers to working folders and up loading all the source to the Codeplex TFS server and testing Lizard against that.
After that, back to features list, and on to a Beta release!
Saturday, 12 July 2008
Stop press...
I've fixed the problem with the context menus! My 'QueryContextMenu' funtion wasn't returning the number of added items. Huzzah!
Now we should see some progress.
Now we should see some progress.
Quick update
I've been really busy with 'other things' of late, and Lizard has been a bit neglected despite my good intentions.
But a quick update :-
The c++ extensions are still coming along. The additional columns are working nicely. The icon overlays are working - and using the TortoiseOverlays dll, so Lizard will run nicely with TortoiseSVN/CVS installed - thanks to HarriHasler for the tip on that one - and for taking me to task for the c# extensions in the first place.
At the moment I have a weird problem where the menus display great, the first item works, but clicking other items causes menu commands from the main menu to be invoked, not the sub menu. I keep looking through the code for the error but just can't spot it.
Once that is done I just need to re-code the properties page, there are some good examples on CodeProject for property pages so hopefully it won't be too bad.
I am not enjoying this at all though! The mixture of c++, COM and running within the Explorer process and the inherent debugging issues does not make for a fulfilling evening of coding! How many ways can you screw up string handling in c++? I think I've managed about 6,000 so far.
I really want the ability to merge across arbitrary folder and not just direct branches, so that will be the next area to tackle. I hope once the extensions are re-done my enthusiasm will rally!
Sorry to anyone waiting... it will come soon!
Thanks
Ian.
But a quick update :-
The c++ extensions are still coming along. The additional columns are working nicely. The icon overlays are working - and using the TortoiseOverlays dll, so Lizard will run nicely with TortoiseSVN/CVS installed - thanks to HarriHasler for the tip on that one - and for taking me to task for the c# extensions in the first place.
At the moment I have a weird problem where the menus display great, the first item works, but clicking other items causes menu commands from the main menu to be invoked, not the sub menu. I keep looking through the code for the error but just can't spot it.
Once that is done I just need to re-code the properties page, there are some good examples on CodeProject for property pages so hopefully it won't be too bad.
I am not enjoying this at all though! The mixture of c++, COM and running within the Explorer process and the inherent debugging issues does not make for a fulfilling evening of coding! How many ways can you screw up string handling in c++? I think I've managed about 6,000 so far.
I really want the ability to merge across arbitrary folder and not just direct branches, so that will be the next area to tackle. I hope once the extensions are re-done my enthusiasm will rally!
Sorry to anyone waiting... it will come soon!
Thanks
Ian.
Monday, 26 May 2008
The Joys Of C++
Following this discussion it became apparent that the c# shell extensions that LizardTF uses would not do. I originally thought that there would only be an issue if another application also used shell extensions, and used an incompatible CLR. I was wrong.
So I've been learning some c++.
I've got the menus working! and I'm hoping that most of the pain is now behind me (Getting to grips with c++ libraries and linker errors is not all that fun). But now there's a tcp/ip based transport in place (pretty basic string stuff) for Lizard so serve up the info, and my c++ extension classes are connecting up okay and passing in requests and processing results. I've got Michael Dunn's excellent articles on shell extensions from CodeProject, which I already used as a basis for the c# code, so I'm hoping to get the full set done over the next month, and then pray I haven't caused any major memory leaks along the way. It's a long time since I've coding without built in memory management.
On another note, I have finished (I think) the 'History through Branches' option on the history screen, this does pretty much what the name suggests, and shows the history from the originating branch(es). This was more of a pig than I had hoped, especially when I was trying to keep the selected block sizes all working. It's all looking good, but I haven't given it a full test on a big, real source repository with some complex branching. This should be complete soon.
The Lizard systray icon will (next release) have a little menu to jump straight into a beefed up repository browser, work items or label search. The repository browser now has full support for deleted items and you can browser/compare at any folder, branch or version and view or get any items/folders.
There is a currently experimental feature that uses FileSystem watchers and can automatically check out files that are changed, this seems to be working well, but I need to see what happens when used at the same time as TeamExplorer is doing a large get.
Work as slowed up a bit after crunching through a lot of functionalty, now I'm down to the trickier bits, but once the new shell extensions are done I want to look to releasing once a month, and hopefully will move to Beta (wahey!) quite soon.
The feedback I've had so far as been quite positive, so thanks for that. Please do let me know if something is broken, not right, too slow or difficult to use; and please let me know if you have any desired features not currently present or planned.
I'm hoping to open this project up to collaborators once it becomes Beta and I have a chance to go through, tidy and comment some of the code, so let me know if you think this might be your sort of thing.
So I've been learning some c++.
I've got the menus working! and I'm hoping that most of the pain is now behind me (Getting to grips with c++ libraries and linker errors is not all that fun). But now there's a tcp/ip based transport in place (pretty basic string stuff) for Lizard so serve up the info, and my c++ extension classes are connecting up okay and passing in requests and processing results. I've got Michael Dunn's excellent articles on shell extensions from CodeProject, which I already used as a basis for the c# code, so I'm hoping to get the full set done over the next month, and then pray I haven't caused any major memory leaks along the way. It's a long time since I've coding without built in memory management.
On another note, I have finished (I think) the 'History through Branches' option on the history screen, this does pretty much what the name suggests, and shows the history from the originating branch(es). This was more of a pig than I had hoped, especially when I was trying to keep the selected block sizes all working. It's all looking good, but I haven't given it a full test on a big, real source repository with some complex branching. This should be complete soon.
The Lizard systray icon will (next release) have a little menu to jump straight into a beefed up repository browser, work items or label search. The repository browser now has full support for deleted items and you can browser/compare at any folder, branch or version and view or get any items/folders.
There is a currently experimental feature that uses FileSystem watchers and can automatically check out files that are changed, this seems to be working well, but I need to see what happens when used at the same time as TeamExplorer is doing a large get.
Work as slowed up a bit after crunching through a lot of functionalty, now I'm down to the trickier bits, but once the new shell extensions are done I want to look to releasing once a month, and hopefully will move to Beta (wahey!) quite soon.
The feedback I've had so far as been quite positive, so thanks for that. Please do let me know if something is broken, not right, too slow or difficult to use; and please let me know if you have any desired features not currently present or planned.
I'm hoping to open this project up to collaborators once it becomes Beta and I have a chance to go through, tidy and comment some of the code, so let me know if you think this might be your sort of thing.
Subscribe to:
Posts (Atom)