Type Converter Suggestion...

Posts   
 
    
C4 avatar
C4
User
Posts: 32
Joined: 12-Nov-2005
# Posted on: 04-May-2006 09:22:29   

I like how when a project is loaded and the typeconverter cannot be found it allows me to search and find the missing assemblies. Is it possible to have the project save the location to where it found it, so next time I load the project, it knows where to find the assemblies??

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 04-May-2006 10:12:20   

I already explained this to you earlier in a helpdesk reply. This can't be done as the information should then be stored inside the project, but that information is inaccessable until the project is loaded but the exceptions occur DURING the project load... so it's not solvable.

I really really REALLY hate the situation as well, but I can't fix it. disappointed I also thought about moving all the type definitions of the fields to strings, but that would break a LOT of code, so I dropped that as well... disappointed Sorry.

Frans Bouma | Lead developer LLBLGen Pro
C4 avatar
C4
User
Posts: 32
Joined: 12-Nov-2005
# Posted on: 06-May-2006 04:28:01   

Otis wrote:

I already explained this to you earlier in a helpdesk reply. This can't be done as the information should then be stored inside the project, but that information is inaccessable until the project is loaded but the exceptions occur DURING the project load... so it's not solvable.

I really really REALLY hate the situation as well, but I can't fix it. disappointed I also thought about moving all the type definitions of the fields to strings, but that would break a LOT of code, so I dropped that as well... disappointed Sorry.

Since this is a new version, and we know this limitation exists, how about a metafile that gets created only if the following conditions exists:

1) TypeConverters were used 2) The TypeConverter could not be found (upon loading project) 3) We browsed to a valid location of where the typeconverter loaded successfully

and we save in this metafile the location to where the typeconverter assembly was found and save it in the same folder as the project file...

Then next time we load the project, and the typeconverter is not found, we worst case scenario default the browse for dll to the location stored in the metafile; and best case scenario we load the typeconverters without the end user knowing.

Your thoughts?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 06-May-2006 09:26:12   

I thought about that but the thing with 2-file projects is that either the files get out of sync, lost etc. which is confusing and cumbersome.

It's not a situation I'm fond of, please understand that. I also couldn't come up with a way to make this work once and for all... without falling back to multi-file stuff, which is a pain to maintain, as people tend to copy 'the project file' around and forget about the other files which are belonging to the project.

Frans Bouma | Lead developer LLBLGen Pro
C4 avatar
C4
User
Posts: 32
Joined: 12-Nov-2005
# Posted on: 06-May-2006 20:09:00   

Otis wrote:

I thought about that but the thing with 2-file projects is that either the files get out of sync, lost etc. which is confusing and cumbersome.

It's not a situation I'm fond of, please understand that. I also couldn't come up with a way to make this work once and for all... without falling back to multi-file stuff, which is a pain to maintain, as people tend to copy 'the project file' around and forget about the other files which are belonging to the project.

Yeah, but worst case scenario is: you have to redefine the location to the type converter. (should the metafile get lost) That's not that big of an impact is it?

Plus we implement this two-file solution only when certain conditions are met. Which should hopefully eliminate a percentage of users from even getting to the two file option. But for those of us that do, this solution would be greatly appreciated, and the minor changes a developer would have to endure would fit in nicely since there are breaking changes with V2 we have to be aware of anyhow. Seems like a perfect time to add this solution to the product.

Please don't think bad of me for pressing the issue. I'm just a developer who fell in love with with your brain child (LLBLGen Pro) and would like to see it be the best it can possibly be by making it even easier and more powerful to use for developers like myself. stuck_out_tongue_winking_eye

C4 avatar
C4
User
Posts: 32
Joined: 12-Nov-2005
# Posted on: 07-May-2006 01:54:41   

Another suggestion I have for the Type Converters that should be fairly easy to implement would be:

In the designer, when selected which type converter to assign to a field, can we have the drop down list sorted alphabetically? That would make it easier to find the typeconverter especially when you have a lot.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 08-May-2006 17:49:59   

I'll look into a fallback file for the project to specify folders for unresolved assemblies. It will be XML I think, which then should give the proper folders to look for the assemblies. If those folders are still not sufficient I'll then move to the popup dialog currently shown.

This is a last-resort option, so typically people don't need it, but if you do, it's there.

Frans Bouma | Lead developer LLBLGen Pro
C4 avatar
C4
User
Posts: 32
Joined: 12-Nov-2005
# Posted on: 10-May-2006 23:46:15   

Otis wrote:

I'll look into a fallback file for the project to specify folders for unresolved assemblies. It will be XML I think, which then should give the proper folders to look for the assemblies. If those folders are still not sufficient I'll then move to the popup dialog currently shown.

This is a last-resort option, so typically people don't need it, but if you do, it's there.

stuck_out_tongue_winking_eye AWESOME! stuck_out_tongue_winking_eye

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 11-May-2006 18:17:26   

Ok, it works like this: you have to specify a file with the filename: projectname.lgp.AssemblyLocations. In that file, you write simple xml where you define the location of an assembly with a given name.

Example:


<assemblyLocations>
    <assemblyLocation name="TestConverters, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" filename="..\TypeConvertersTest\TestConverters\bin\Debug\TestConverters.dll"/>
</assemblyLocations>

As you can see, you can specify paths relative to the project file location. Now, at project load, this file is read first. Then the project. It can be that an assembly isn't found during project load, in which case the contents of this file is checked. If a match is found the file is loaded using the filename specified. If the assembly name isn't found the dialog still pops up.

You now can also use the AdditionalTypeConvertersFolder in the project, just leave the type converters there. simple_smile

So, simple solution to a nagging problem. Hopefully it solves your project load problems. simple_smile . This is available in the next build, which will be uploaded shortly.

Frans Bouma | Lead developer LLBLGen Pro