I've just pushed out version 5.72 of Web Connection. If you're a registered user you should have received an update notification for the registered download. If you're a new user you can download the latest version from the Web Connection web site:
http://west-wind.com/webconnection
What's new?
There is a host of new functionality. Nothing really major except possibly the debugging features for server startup which hopefully should make life a lot easier for those of you that have run into problems with COM server startup issues.
Here are some of the highlights.
Improved Startup Error Handling
If you've run into startup errors in COM server, you probably know that it can be really difficult to debug these types of problems. The issue is that COM servers launch by invoking the Init() method of the server and Web Connection fires your server startup code off the code that is internal to Init(). If a COM server is launched and there's an error in your startup code, the COM server fails to create and you get a very non-descript COM error returned, which usually tells you nothing. In the past there's been no error trapping for this so there wasn't even any information available.
In this release I've added explicit initialization error trapping code, so both the OnInit() and OnLoad() code that executes your user code is now wrapped in TRY/CATCH handlers which capture any errors and try to log them into the standard Web Connection Error log. At the very least you will now get an entry in wwRequestLog (or your SQL Server log (if that's been activated yet).
Additionally the capture exception is also routed to wwServer::OnError(), which you can override and log the exception to your own storage or notification api.
This is a simple change that should greatly improve debugging for startup problems especially in COM.
wwServer::Trace
Related to the server debugging is the fact that sometimes, even with error handling you need to find a crash and locate exactly what code is blowing up in your server. While the various Web Connection error handlers will catch any exceptions in your user code, the error messages FoxPro provides in a running EXE based application often are misleading or pointing at the wrong code. Sometimes you simply need to use the WriteLine() based debugging.
In Web applications WriteLine() based debugging essentially means you write messages to a log file. To this end there's now a simple wwServer.Trace() method which allows you to simply call Server.Trace() (or THIS.Trace() in yourServer code) with a message, which by default logs to a wcTraceLog.txt file in the application's startup folder. It's a simple way to write out messages that let you know that code has gone to a certain location and provide any state information that you need for you to aid in debugging.
THis is especially useful in startup code debugging, because as mentioned above it's difficult to get a meaningful error message from COM. Tracelogs at least will allow you to try to pin down where errors occur.
One caveat: Trace() writes to a file, which while fast is a locking operation. If you have multiple instances running this can slow down your application. Make sure you remove any Trace() statements() when you're done debugging.
New wwEncryption Class
I've added a new wwEncryption class to Web Connection to provide an easy way to do both two-way value encryption and one-way hash encryption. Two-way encryption is typically used for encrypting operational values in configuration files, while one-way hashes tend to be used in password or token encryption. In the latter you write out hashed values to your database and then always re-encode user input to see whether it matches a given hashed value. Encryption uses TripleDES encryption while hashing supports MD5 and various SHA strengths up to SHA512.
The wwEncryption class uses wwDotnetBridge and a set of embedded encryption helpers that now exist in wwDotnetBridge. If there's interest I can add additional encryption and encoding features later, but the most common use cases are covered by the Encrypt/Decrypt pair and the ComputeHash function.
Tons of tweaks and improvements for wwDotnetBridge
Since wwDotnetBridge was made open source adoption of the library has gone way up and I've seen a bunch of new edge cases reported, that have been addressed in this release. There now full support for calling methods with ByRef parameters with result values updated when using ComValue objects. You can now also capture inaccessible values from method calls by using ComValue::SetValueFromInvokeMethod() and ComValue::SetValueFromInvokeStaticMethod(). These funky named methods allow you to access values that FoxPro would otherwise not be able to return to you such as value types, structs, generic objects, or some simple types like Longs, Single, DbNulls etc. Web Connection automatically detects most of these types and properly converts them into something that you can use in Foxpro.
Updated Message Board
There have been a number of changes in the message board sample, and those changes are now reflected in the code that ships with Web Connection. Among others there's support for async image uploads and embedding, pinning of messages and a new thread view that allows showing all messags in a thread.
Hopefully you will find some useful improvements in this version. As always if you run into any issues or failures, or you have ideas on how to improve things please post a message to let us know. Let's keep the Web Connection discussion alive.
+++ Rick ---
Everything runs now. I assume I'm not missing anything.
Hi all,
I've just pushed out version 5.72 of Web Connection. If you're a registered user you should have received an update notification for the registered download. If you're a new user you can download the latest version from the Web Connection web site:
http://west-wind.com/webconnection
What's new?
There is a host of new functionality. Nothing really major except possibly the debugging features for server startup which hopefully should make life a lot easier for those of you that have run into problems with COM server startup issues.
Here are some of the highlights.
Improved Startup Error Handling
If you've run into startup errors in COM server, you probably know that it can be really difficult to debug these types of problems. The issue is that COM servers launch by invoking the Init() method of the server and Web Connection fires your server startup code off the code that is internal to Init(). If a COM server is launched and there's an error in your startup code, the COM server fails to create and you get a very non-descript COM error returned, which usually tells you nothing. In the past there's been no error trapping for this so there wasn't even any information available.
In this release I've added explicit initialization error trapping code, so both the OnInit() and OnLoad() code that executes your user code is now wrapped in TRY/CATCH handlers which capture any errors and try to log them into the standard Web Connection Error log. At the very least you will now get an entry in wwRequestLog (or your SQL Server log (if that's been activated yet).
Additionally the capture exception is also routed to wwServer::OnError(), which you can override and log the exception to your own storage or notification api.
This is a simple change that should greatly improve debugging for startup problems especially in COM.
wwServer::Trace
Related to the server debugging is the fact that sometimes, even with error handling you need to find a crash and locate exactly what code is blowing up in your server. While the various Web Connection error handlers will catch any exceptions in your user code, the error messages FoxPro provides in a running EXE based application often are misleading or pointing at the wrong code. Sometimes you simply need to use the WriteLine() based debugging.
In Web applications WriteLine() based debugging essentially means you write messages to a log file. To this end there's now a simple wwServer.Trace() method which allows you to simply call Server.Trace() (or THIS.Trace() in yourServer code) with a message, which by default logs to a wcTraceLog.txt file in the application's startup folder. It's a simple way to write out messages that let you know that code has gone to a certain location and provide any state information that you need for you to aid in debugging.
THis is especially useful in startup code debugging, because as mentioned above it's difficult to get a meaningful error message from COM. Tracelogs at least will allow you to try to pin down where errors occur.
One caveat: Trace() writes to a file, which while fast is a locking operation. If you have multiple instances running this can slow down your application. Make sure you remove any Trace() statements() when you're done debugging.
New wwEncryption Class
I've added a new wwEncryption class to Web Connection to provide an easy way to do both two-way value encryption and one-way hash encryption. Two-way encryption is typically used for encrypting operational values in configuration files, while one-way hashes tend to be used in password or token encryption. In the latter you write out hashed values to your database and then always re-encode user input to see whether it matches a given hashed value. Encryption uses TripleDES encryption while hashing supports MD5 and various SHA strengths up to SHA512.
The wwEncryption class uses wwDotnetBridge and a set of embedded encryption helpers that now exist in wwDotnetBridge. If there's interest I can add additional encryption and encoding features later, but the most common use cases are covered by the Encrypt/Decrypt pair and the ComputeHash function.
Tons of tweaks and improvements for wwDotnetBridge
Since wwDotnetBridge was made open source adoption of the library has gone way up and I've seen a bunch of new edge cases reported, that have been addressed in this release. There now full support for calling methods with ByRef parameters with result values updated when using ComValue objects. You can now also capture inaccessible values from method calls by using ComValue::SetValueFromInvokeMethod() and ComValue::SetValueFromInvokeStaticMethod(). These funky named methods allow you to access values that FoxPro would otherwise not be able to return to you such as value types, structs, generic objects, or some simple types like Longs, Single, DbNulls etc. Web Connection automatically detects most of these types and properly converts them into something that you can use in Foxpro.
Updated Message Board
There have been a number of changes in the message board sample, and those changes are now reflected in the code that ships with Web Connection. Among others there's support for async image uploads and embedding, pinning of messages and a new thread view that allows showing all messags in a thread.
Hopefully you will find some useful improvements in this version. As always if you run into any issues or failures, or you have ideas on how to improve things please post a message to let us know. Let's keep the Web Connection discussion alive.
+++ Rick ---
+++ Rick ---
I did a virgin install of Version 5.72 and it appears wwBusiness.vct was omitted from \wconnect\classes in the zip file. In order to get it to work, I had to copy the classlib from 5.70. I think you skipped 5.71?
Everything runs now. I assume I'm not missing anything.
Hi all,
I've just pushed out version 5.72 of Web Connection. If you're a registered user you should have received an update notification for the registered download. If you're a new user you can download the latest version from the Web Connection web site:
http://west-wind.com/webconnection
What's new?
There is a host of new functionality. Nothing really major except possibly the debugging features for server startup which hopefully should make life a lot easier for those of you that have run into problems with COM server startup issues.
Here are some of the highlights.
Improved Startup Error Handling
If you've run into startup errors in COM server, you probably know that it can be really difficult to debug these types of problems. The issue is that COM servers launch by invoking the Init() method of the server and Web Connection fires your server startup code off the code that is internal to Init(). If a COM server is launched and there's an error in your startup code, the COM server fails to create and you get a very non-descript COM error returned, which usually tells you nothing. In the past there's been no error trapping for this so there wasn't even any information available.
In this release I've added explicit initialization error trapping code, so both the OnInit() and OnLoad() code that executes your user code is now wrapped in TRY/CATCH handlers which capture any errors and try to log them into the standard Web Connection Error log. At the very least you will now get an entry in wwRequestLog (or your SQL Server log (if that's been activated yet).
Additionally the capture exception is also routed to wwServer::OnError(), which you can override and log the exception to your own storage or notification api.
This is a simple change that should greatly improve debugging for startup problems especially in COM.
wwServer::Trace
Related to the server debugging is the fact that sometimes, even with error handling you need to find a crash and locate exactly what code is blowing up in your server. While the various Web Connection error handlers will catch any exceptions in your user code, the error messages FoxPro provides in a running EXE based application often are misleading or pointing at the wrong code. Sometimes you simply need to use the WriteLine() based debugging.
In Web applications WriteLine() based debugging essentially means you write messages to a log file. To this end there's now a simple wwServer.Trace() method which allows you to simply call Server.Trace() (or THIS.Trace() in yourServer code) with a message, which by default logs to a wcTraceLog.txt file in the application's startup folder. It's a simple way to write out messages that let you know that code has gone to a certain location and provide any state information that you need for you to aid in debugging.
THis is especially useful in startup code debugging, because as mentioned above it's difficult to get a meaningful error message from COM. Tracelogs at least will allow you to try to pin down where errors occur.
One caveat: Trace() writes to a file, which while fast is a locking operation. If you have multiple instances running this can slow down your application. Make sure you remove any Trace() statements() when you're done debugging.
New wwEncryption Class
I've added a new wwEncryption class to Web Connection to provide an easy way to do both two-way value encryption and one-way hash encryption. Two-way encryption is typically used for encrypting operational values in configuration files, while one-way hashes tend to be used in password or token encryption. In the latter you write out hashed values to your database and then always re-encode user input to see whether it matches a given hashed value. Encryption uses TripleDES encryption while hashing supports MD5 and various SHA strengths up to SHA512.
The wwEncryption class uses wwDotnetBridge and a set of embedded encryption helpers that now exist in wwDotnetBridge. If there's interest I can add additional encryption and encoding features later, but the most common use cases are covered by the Encrypt/Decrypt pair and the ComputeHash function.
Tons of tweaks and improvements for wwDotnetBridge
Since wwDotnetBridge was made open source adoption of the library has gone way up and I've seen a bunch of new edge cases reported, that have been addressed in this release. There now full support for calling methods with ByRef parameters with result values updated when using ComValue objects. You can now also capture inaccessible values from method calls by using ComValue::SetValueFromInvokeMethod() and ComValue::SetValueFromInvokeStaticMethod(). These funky named methods allow you to access values that FoxPro would otherwise not be able to return to you such as value types, structs, generic objects, or some simple types like Longs, Single, DbNulls etc. Web Connection automatically detects most of these types and properly converts them into something that you can use in Foxpro.
Updated Message Board
There have been a number of changes in the message board sample, and those changes are now reflected in the code that ships with Web Connection. Among others there's support for async image uploads and embedding, pinning of messages and a new thread view that allows showing all messags in a thread.
Hopefully you will find some useful improvements in this version. As always if you run into any issues or failures, or you have ideas on how to improve things please post a message to let us know. Let's keep the Web Connection discussion alive.
+++ Rick ---
West Wind Technologies
Making waves on the Web
from Maui
When did you download? THe very immediate release I pushed out had a couple of files missing but I believe the current download includes this file. I can't recall if it was this one but I think I would have heard about this by now.
+++ Rick ---
I did a virgin install of Version 5.72 and it appears wwBusiness.vct was omitted from \wconnect\classes in the zip file. In order to get it to work, I had to copy the classlib from 5.70. I think you skipped 5.71?
Everything runs now. I assume I'm not missing anything.
Hi all,
I've just pushed out version 5.72 of Web Connection. If you're a registered user you should have received an update notification for the registered download. If you're a new user you can download the latest version from the Web Connection web site:
http://west-wind.com/webconnection
What's new?
There is a host of new functionality. Nothing really major except possibly the debugging features for server startup which hopefully should make life a lot easier for those of you that have run into problems with COM server startup issues.
Here are some of the highlights.
Improved Startup Error Handling
If you've run into startup errors in COM server, you probably know that it can be really difficult to debug these types of problems. The issue is that COM servers launch by invoking the Init() method of the server and Web Connection fires your server startup code off the code that is internal to Init(). If a COM server is launched and there's an error in your startup code, the COM server fails to create and you get a very non-descript COM error returned, which usually tells you nothing. In the past there's been no error trapping for this so there wasn't even any information available.
In this release I've added explicit initialization error trapping code, so both the OnInit() and OnLoad() code that executes your user code is now wrapped in TRY/CATCH handlers which capture any errors and try to log them into the standard Web Connection Error log. At the very least you will now get an entry in wwRequestLog (or your SQL Server log (if that's been activated yet).
Additionally the capture exception is also routed to wwServer::OnError(), which you can override and log the exception to your own storage or notification api.
This is a simple change that should greatly improve debugging for startup problems especially in COM.
wwServer::Trace
Related to the server debugging is the fact that sometimes, even with error handling you need to find a crash and locate exactly what code is blowing up in your server. While the various Web Connection error handlers will catch any exceptions in your user code, the error messages FoxPro provides in a running EXE based application often are misleading or pointing at the wrong code. Sometimes you simply need to use the WriteLine() based debugging.
In Web applications WriteLine() based debugging essentially means you write messages to a log file. To this end there's now a simple wwServer.Trace() method which allows you to simply call Server.Trace() (or THIS.Trace() in yourServer code) with a message, which by default logs to a wcTraceLog.txt file in the application's startup folder. It's a simple way to write out messages that let you know that code has gone to a certain location and provide any state information that you need for you to aid in debugging.
THis is especially useful in startup code debugging, because as mentioned above it's difficult to get a meaningful error message from COM. Tracelogs at least will allow you to try to pin down where errors occur.
One caveat: Trace() writes to a file, which while fast is a locking operation. If you have multiple instances running this can slow down your application. Make sure you remove any Trace() statements() when you're done debugging.
New wwEncryption Class
I've added a new wwEncryption class to Web Connection to provide an easy way to do both two-way value encryption and one-way hash encryption. Two-way encryption is typically used for encrypting operational values in configuration files, while one-way hashes tend to be used in password or token encryption. In the latter you write out hashed values to your database and then always re-encode user input to see whether it matches a given hashed value. Encryption uses TripleDES encryption while hashing supports MD5 and various SHA strengths up to SHA512.
The wwEncryption class uses wwDotnetBridge and a set of embedded encryption helpers that now exist in wwDotnetBridge. If there's interest I can add additional encryption and encoding features later, but the most common use cases are covered by the Encrypt/Decrypt pair and the ComputeHash function.
Tons of tweaks and improvements for wwDotnetBridge
Since wwDotnetBridge was made open source adoption of the library has gone way up and I've seen a bunch of new edge cases reported, that have been addressed in this release. There now full support for calling methods with ByRef parameters with result values updated when using ComValue objects. You can now also capture inaccessible values from method calls by using ComValue::SetValueFromInvokeMethod() and ComValue::SetValueFromInvokeStaticMethod(). These funky named methods allow you to access values that FoxPro would otherwise not be able to return to you such as value types, structs, generic objects, or some simple types like Longs, Single, DbNulls etc. Web Connection automatically detects most of these types and properly converts them into something that you can use in Foxpro.
Updated Message Board
There have been a number of changes in the message board sample, and those changes are now reflected in the code that ships with Web Connection. Among others there's support for async image uploads and embedding, pinning of messages and a new thread view that allows showing all messags in a thread.
Hopefully you will find some useful improvements in this version. As always if you run into any issues or failures, or you have ideas on how to improve things please post a message to let us know. Let's keep the Web Connection discussion alive.
+++ Rick ---
BTW I double checked and sure enough wwBusiness *was* missing. I updated the download and it's in there.
I guess not a lot of new customers - existing customers would do as you do - update on top of the existing version.
Thanks for pointing it out.
Aloha,
+++ Rick ---
OK - When I initially updated, I installed over 5.70 so I never saw a bug.
When did you download? THe very immediate release I pushed out had a couple of files missing but I believe the current download includes this file. I can't recall if it was this one but I think I would have heard about this by now.
+++ Rick ---
I did a virgin install of Version 5.72 and it appears wwBusiness.vct was omitted from \wconnect\classes in the zip file. In order to get it to work, I had to copy the classlib from 5.70. I think you skipped 5.71?
Everything runs now. I assume I'm not missing anything.
Hi all,
I've just pushed out version 5.72 of Web Connection. If you're a registered user you should have received an update notification for the registered download. If you're a new user you can download the latest version from the Web Connection web site:
http://west-wind.com/webconnection
What's new?
There is a host of new functionality. Nothing really major except possibly the debugging features for server startup which hopefully should make life a lot easier for those of you that have run into problems with COM server startup issues.
Here are some of the highlights.
Improved Startup Error Handling
If you've run into startup errors in COM server, you probably know that it can be really difficult to debug these types of problems. The issue is that COM servers launch by invoking the Init() method of the server and Web Connection fires your server startup code off the code that is internal to Init(). If a COM server is launched and there's an error in your startup code, the COM server fails to create and you get a very non-descript COM error returned, which usually tells you nothing. In the past there's been no error trapping for this so there wasn't even any information available.
In this release I've added explicit initialization error trapping code, so both the OnInit() and OnLoad() code that executes your user code is now wrapped in TRY/CATCH handlers which capture any errors and try to log them into the standard Web Connection Error log. At the very least you will now get an entry in wwRequestLog (or your SQL Server log (if that's been activated yet).
Additionally the capture exception is also routed to wwServer::OnError(), which you can override and log the exception to your own storage or notification api.
This is a simple change that should greatly improve debugging for startup problems especially in COM.
wwServer::Trace
Related to the server debugging is the fact that sometimes, even with error handling you need to find a crash and locate exactly what code is blowing up in your server. While the various Web Connection error handlers will catch any exceptions in your user code, the error messages FoxPro provides in a running EXE based application often are misleading or pointing at the wrong code. Sometimes you simply need to use the WriteLine() based debugging.
In Web applications WriteLine() based debugging essentially means you write messages to a log file. To this end there's now a simple wwServer.Trace() method which allows you to simply call Server.Trace() (or THIS.Trace() in yourServer code) with a message, which by default logs to a wcTraceLog.txt file in the application's startup folder. It's a simple way to write out messages that let you know that code has gone to a certain location and provide any state information that you need for you to aid in debugging.
THis is especially useful in startup code debugging, because as mentioned above it's difficult to get a meaningful error message from COM. Tracelogs at least will allow you to try to pin down where errors occur.
One caveat: Trace() writes to a file, which while fast is a locking operation. If you have multiple instances running this can slow down your application. Make sure you remove any Trace() statements() when you're done debugging.
New wwEncryption Class
I've added a new wwEncryption class to Web Connection to provide an easy way to do both two-way value encryption and one-way hash encryption. Two-way encryption is typically used for encrypting operational values in configuration files, while one-way hashes tend to be used in password or token encryption. In the latter you write out hashed values to your database and then always re-encode user input to see whether it matches a given hashed value. Encryption uses TripleDES encryption while hashing supports MD5 and various SHA strengths up to SHA512.
The wwEncryption class uses wwDotnetBridge and a set of embedded encryption helpers that now exist in wwDotnetBridge. If there's interest I can add additional encryption and encoding features later, but the most common use cases are covered by the Encrypt/Decrypt pair and the ComputeHash function.
Tons of tweaks and improvements for wwDotnetBridge
Since wwDotnetBridge was made open source adoption of the library has gone way up and I've seen a bunch of new edge cases reported, that have been addressed in this release. There now full support for calling methods with ByRef parameters with result values updated when using ComValue objects. You can now also capture inaccessible values from method calls by using ComValue::SetValueFromInvokeMethod() and ComValue::SetValueFromInvokeStaticMethod(). These funky named methods allow you to access values that FoxPro would otherwise not be able to return to you such as value types, structs, generic objects, or some simple types like Longs, Single, DbNulls etc. Web Connection automatically detects most of these types and properly converts them into something that you can use in Foxpro.
Updated Message Board
There have been a number of changes in the message board sample, and those changes are now reflected in the code that ships with Web Connection. Among others there's support for async image uploads and embedding, pinning of messages and a new thread view that allows showing all messags in a thread.
Hopefully you will find some useful improvements in this version. As always if you run into any issues or failures, or you have ideas on how to improve things please post a message to let us know. Let's keep the Web Connection discussion alive.
+++ Rick ---
West Wind Technologies
Making waves on the Web
from Maui
Arghh... yup, uploaded the file to the wrong location. It's there now...
Thanks,
+++ Rick ---
I downloaded it today and wwBusiness class is still missing.
West Wind Technologies
Making waves on the Web
from Maui
--stein
Arghh... yup, uploaded the file to the wrong location. It's there now...
Thanks,
+++ Rick ---
I downloaded it today and wwBusiness class is still missing.
I don't think there were any changes at all. if there were they were minor tweaks or fixes. But - probably not a bad idea to download and just grab the wwbusiness files out of the zip.
+++ Rick ---
I already upgraded to 5.72 from 5.70 - would there have been any changes to wwBusiness that would make it worthwhile to get the missing files?
--stein
Arghh... yup, uploaded the file to the wrong location. It's there now...
Thanks,
+++ Rick ---
I downloaded it today and wwBusiness class is still missing.
West Wind Technologies
Making waves on the Web
from Maui