July 2004 - Posts
While reading the VSTO setup instructions, I found the following paragraph under the “Troubleshooting Setup”:
- Issue: High contrast mode hides text in the Setup wizard.
If you have your monitor set to use High Contrast, the text in the Setup wizard is not visible.
To view the text in the Setup Wizard
Open the Control Panel, choose Accessibility Options, and then click the Display tab.
Clear the Use High Contrast option.
Run Setup for Visual Studio Tools for the Microsoft Office System again.
It's not the first time I read setup instruction, however this is the first time I see a setup issue regarding the contrast settings of the monitor. But why stop there? Maybe there is a problem in the brightness settings? Or even better - maybe the monitor is not turned on!
MS guys, is there any special reason for listing this problem?
Since I'm responsible for .NET and J2EE projects, I have two different IDE on my machine: VS.NET and WSAD (WebSphere Studio Application Developer). I use also two different source control tools: VSS for the .NET, Rational ClearCase for the J2EE.
After I've installed the ClearCase and worked some time on the WSAD, I wanted to switch to the VS.NET. So, naturally, I opened it up and tried to open our project. To my surprise, some strange error messages appeared. Those error messages, which were raised by VSS, stated that “The operation could not be completed.” After the messages - I couldn't open my project, and it was marked as “unavailable”.
I did some research on google, but couldn't find anything useful, that helped solve the problem. But - I did find some remarks stating that VSS and ClearCase on the same machine could be quite problematic.
Next station was the registry. After an extensive research, it turned out that there is a specific registry key that the IDE (both of them!) looks into to see whether a specific SourceControl is installed. For some unknown reason (to me), there is no value in there for source safe, only for ClearCase. This value should be removed prior using the VSS. If it is there - the VSS integration in VS.NET won't work.
So, here is a step by step instructions to re-enable VSS on a machine with ClearCase installed:
1. Open RegEdit
(Imagine that all the regular yada yada about the dangers in messing with the Registry is written right here.)
2. Navigate to: HKEY_LOCAL_MACHINE/SOFTWARE/SourceCodeControlProvider/InstalledSCCProviders
3. If ClearCase is installed, you should see one entry (besides the “(Default)”) named “ClearCase”, with the value “Software\Atria\ClearCase”. Remove the entry.
4. Now try to work with VSS under VS.NET. It should work.
If you would like to re-enable ClearCase later, simply add the entry mentioned above.
After a few rounds of adding / deleting from the registry, I became quite tired from this procedure, so I wrote a little tool which performs this exact task. If you're interested - email me and I'll send it back to you. Just remember that this tool requires the .NET runtime on your machine (quite obvious, but you can never know...)
One of the frequent problems we encounter while developing web applications is how to inform the user about an action that has been performed.
Take, for example, the following (quite common) scenario:
A user types data in some textboxes on the page, and clicks the “Save” button. The page submits itself, saves the data in the database, and redisplay. What should happen now? How are we going to inform the user that the save completed successfuly? Basically, we have three options, but IMHO each one of them is not good enough:
1. Display a popup window with the confirmation message - This is a bad alternative, since we force the user to perform some action (clicking the “Ok” button of the popup) without any reason. There was nothing wrong, and nothing should interfere with his regular flow of work.
2. Display a message in the browser's status bar - Not good. Often the browser decides by itself what would be displayed in the status bar, and our custom text could be quickly replaced by “Done”, “Opening page...”, or even “Error on page”. In addition, there is no control at all on the icon that will be displayed. Because of all the reasons above, the average user does not even looks at the status bar - he thinks he already knows what is in there (unlike dedicated classic client / server app).
3. Dedicate special area on the screen for messages - Wrong again. Screen area is an expensive resource, and in web environment it is even more scarce, with all the browser's toolbars (again, not a problem in a client / server app). This solution may work well for applications which should run on high res screens (1024 X 768 and above. Unlikely enough, most users still prefer the old 800 X 600 res) and have very few objects on screen, but if your page contains 10 textboxes + 15 tabs containing textboxes, grids and drop downs (as many of are pages are), you'll think twice before sacrificing 2 cm of the screen for messages which will be rarely displayed.
So, bottom line: we depend on the user to understand that if the page reloaded, and no error message appeared, then everything worked just fine.
What do you think about that? What is your approach to this issue?
I am now functioning (beside the regular technological activities) as a team leader for two parallel projects in our company - one medium (web based) .NET project, and one huge J2EE project. This has been the reason for lack of writing lately.
This is of course a good opportunity to compare the two technologies, although I'm not going to (re-)open a holy war, nor am I consider myself being Java expert.
Anyway, one of the (surprising) problems we encounter in the J2EE environment is no less than the Java equivalent to the DLL Hell.
In both projects, we maintain three environments: Dev, QA and Prod. For each project, the three environments are on the same server (.NET 1.1 on win2003 for the .NET project, WebSphere 5.02 on AS/400 for the J2EE one), and have their own database (SQL Server and DB2, respectively). When we want to deliver new modules to the QA env of the .NET project, we just...well...copy it. Maybe some changes in the web.config to direct to the appropriate database, but that's all, actually.
To my big surprise, this was not the situation in the J2EE project. This project rely heaviliy on CMP EJB (in short: O/R mapping technology for distributed applications in the J2EE environment. Has some common features with the yet-to-come ObjectSpaces.). Looks like the application server (WAS 5, as mentioned before) cannot maintain two versions of EJB, and the result is the Dev and QA talks to the same database. Once there is one EJB “registered“ in the WebSphere, you cannot hold another one with the same name, but of different version. Sounds familiar?
I have a full time programmer trying to solve that for already two weeks, and on Thursday last week he was helped by some WebSphere expert. We'll know tomorrow whether the problem was solved or not.
We are developing an application which should display map to the user, allowing him to click on a specific regions on it. Problem is - the map is big, the screen is small (relatively, that is...). We didn't want to have a big scroller, because the user won't have a full prespective on the map.