Issues with WeBuider 2005

[Grzegorz]

I've just downloaded WeBuider and started to play with.

Yesterday I posted the question to support team via the web site but haven't received any answer yet. Now I post the issues on the public forum.

1. I use ISO-9959-2 (Latin-2) code page. The HTML file contains:

<META http-equiv="content-type" content="text/html; charset=iso-8859-2">

Now I use Crimson Editor and substitute diacritcal characters: for example instead of "ą" I use "Ā±". Browser (IE & FireFox) display characters property as "ą".

Now I open the HTML file in WBuilder and the editor works without any translation. So how WeBuider handles different codepages. For me it does not. I can use the same trick as in Crimson Editor but WeBuider is specialistic HTML editor.

2. I don't notice how WeBuider handles invalid links ? I modify the HREF= tag that it points to nonexisting file and open Code Explorer. There is not sign that the link is not valid. Maybe I missed something. Or I have to use W3 validators as I use now.

3. WeBuider saves all settings in the registry. So when I reformat & reinstall OS I have to set all settings from scratch. Nonsense. WeBuilder should save settings in INI or XML file.

4. I can't find how to change the background color for a PHP block between <?php and ?>.

5. I'm not a HTML expert but instead of <center> and <p align="center> I use <div align="center">. Maybe in options WBuider should handles this also.

6. I wish to see the long line in wordwrap mode as:

bbalala bbalaal bllalla bbllala.......
bll aa a a aa lll ...
blala bala.

WeBuider uses rather:

bbalala bbalaal bllalla bbllala.......
bll aa a a aa lll ...
blala bala.

7. In 5 minutes after I install WeBuider it bombs with Access Violation. To reproduce: Project -> Manage Project > Edit or Delete button.

Unfortunatly I am a very annoying and demanding customer. I work in IT and I know my needs. At the moment I use Crimson Editor, W3 validators and FileZilla FTP client. Now I'm looking for HTML editor to make easy the managment of my web site.

----
Grzegorz

[Karlis]

Quick replies to your points:

1. If you mean the text editor then no conversion or special display is applied, you can see your code in plain text as it is. If you mean the preview - well, preview is brought by the IE web browsing component, thus you can right-click on the preview and select the encoding of your choice.

2. Links are not checked. Very people create links and only then create the files, so displaying warnings all the time would be too annoying. However you can use third party link validators to check your web site links after all the code is written. Of course such tool can be created inside the editor itself, but it is not our primary focus right now.

3. If you can use registry editor, you cen export and then import back the registry key with no problems. Use the export key command. Settings are stored according to Microsoft guidelines for good Windows software development style.

4. You can not change the background color of PHP block as such, however you can change the background color of all the PHP elements and achieve almost the same effect.

5. Probably you have a good point. however for text formatting <p> is more often used as it is the text container by definition, while the <div> is a layer.

6. They seem identical to me.

7. Will be fixed in a few days.

[Guest]

There is a problem with my message because I posted it as HTML. I switched off HTML in this post now.

1. If you mean the text editor then no conversion or special display is applied, you can see your code in plain text as it is. If you mean the preview - well, preview is brought by the IE web browsing component, thus you can right-click on the preview and select the encoding of your choice.

In editor I write "Ā±" to substitute "ą" character (it's #261). Browser shows OK. The problem is text editor - not browser. In short - I wish the editor makes the convertion between ISO-9959-2 used in HTML file and Windows-1250 used in editor's window.

2. Links are not checked. [...]

In short: please add the marker in Code Explorer that the link is invalid. Don't force me to use third-party tools.

3. If you can use registry editor, you cen export and then import back the registry key with no problems. Use the export key command. Settings are stored according to Microsoft guidelines for good Windows software development style.

I know how to use RegEdit. FYI the registry is obsolete. And WeBuilder saves a few settings in Application Data folder so it's inconsistent.

4. You can not change the background color of PHP block as such, however you can change the background color of all the PHP elements and achieve almost the same effect.

"Almost" but not what I wish.

6. They seem identical to me.

In Crimson Editor:

babba baabab bbjbjba bajabajkh
bbkjk ljjl ll lkll
lkjlllkll

and in WeBuilder:

babba baabab bbjbjba bajabajkh
bbkjk ljjl ll lkll
lkjlllkll


The next line starts from first column.

[Grzegorz Wiktorowski]

3. If you can use registry editor, you cen export and then import back the registry key with no problems. Use the export key command. Settings are stored according to Microsoft guidelines for good Windows software development style.

Today I found another evidence against keeping settings in the registry. I uninstalled 6.02 trail and next installed 6.10 trial. After uninstall all settings have gone. It seems to me that only the installation on the top of the previous version preserves the settings in the registry.

[Karlis]

Yes, you need to install on top of the previous version (upgrade), otherwise the uninstall will wipe the settings thinking that you no more need the program.

[flz]

4. You can not change the background color of PHP block as such, however you can change the background color of all the PHP elements and achieve almost the same effect

My vote for a setting to change the background of PHP-blocks.
I already changed all PHP Elements, but whitespace and some chars in the code (like ++, !, -> etc.) are not recognised, so this looks quite disrupted.

[Karlis]

flz, I see and understand now. Currently the implementation is a technical problem we do not have a solution yet, but I hope to find a solution with the time.

[chrisjlocke]

FYI the registry is obsolete.

I'd like to know where you got that information from. Admittedly, I still use .INI files in my programs as they are quick and easy to tweak, and copy from one machine to another, but the preferred method of saving settings should be via the Registry. It is far from obsolete.

[Grzegorz Wiktorowski]

FYI the registry is obsolete.

I'd like to know where you got that information from.

For example: http://www.devx.com/dotnet/Article/16323/1763/page/1

"....
Interestingly, despite the warning and the touted "advantages" of using the registry, even Microsoft still uses INI files for some purposes, and has reintroduced application meta-information files as XML-formatted "configuration" files in .NET, making the registry obsolete.
...."

Admittedly, I still use .INI files in my programs as they are quick and easy to tweak, and copy from one machine to another...

I keep settings in INI files as well as in the registry. But I'm aware of side effects and what my customers need. I try to minimize their inconveniences.

... but the preferred method of saving settings should be via the Registry. It is far from obsolete.

Sorry but I don't agree. Tell the common user to preserve the setting via RegEdit. He knows how to copy files but not how to save/restore the registry's entries, I'm affraid.

[TomTinsley]

I would have to agree to a degree about the registry. I recently received a new computer and had to migrate my setting from one laptop to another. I do know my way around the registry and can compare the data to decide what needs to be passed from one PC to another. However it is a lot easier when programmers put most, if not all, of the user settings in their system profile directory (example C:\Documents and Settings\%USERNAME%\Application Data). Or at least a settings export feature. Most of the applications I migrated over only required me to put in my serial number and copy the contents of their folder in the C:\Documents and Settings\%USERNAME%\Application Data directory.

[ecarlson66]

Believe it or not, there are IT shops where developers do not have access to their registry settings. (Yes, I know, I should get out post haste but right now I need the stability!) Anyway, I would vote for an ini file.

[Karlis]

There are problems with ini files as well. You can not write ini file when not in admin mode (if the ini file is in the program files directory), so you have to store the ini file separately in "documents and settings". IMHO That is not much easier for users than locating the registry key. Well, maybe it is not too bad also.

As a user I like ini files because thay allow to move easily from one PC to another. I have Program Files 2 directory where I store programs that can be moved without re-installing, and I love it.

P.S. Maybe we need to create some kind of schmooze forum for this kind of talks

[syrupcore]

I'm all for the \user\docs\applicationdata\ folder. So easy to move firefox and the like. You can even use microsofts 'move my crap to a new computer' utility. They have a much more charming name, to be sure.

ini or similar files in there. the only way to go!

Will

[gLes]

I say that to compromise the two sides the settings should stay in the registry and there should be an Export and Import Settings feature implemented. (Maybe it should even be saved to an INI file )

[babedieboe]

Quick replies to your points:

4. You can not change the background color of PHP block as such, however you can change the background color of all the PHP elements and achieve almost the same effect.

every time i do this, after i close the file and re-open, the background colors are resetted to white.....(applied yes:-)
how can i get around this?