I really want the new Data Port Console to go a few steps ahead of the old SQL CE Console when it comes to useability. One of the nice additions to the product is SQL syntax highlighting on the query editor. This allows you to write stuff like:
SELECT * FROM Customers
Fonts and colors are applied as you write and now I want to extend the editor to support auto-completion. Instead of purchasing a costly component, I decided to adapt the code on this article:
Syntax highlighting textbox written in C#
The code has some bugs and gotchas, but it is easy to use and adapt to VS 2005.
Wednesday, September 27, 2006
Saturday, September 23, 2006
Data Port Console
I am in the early stages of development of Data Port Console, the successor to SQL CE Console. After looking at the very long list of UI design errors I decided to use the DockPanel Suite from Weifen Luo. Most of the database editing code is being reused from the old product, but packaged in a much more compelling user interface with tabbed windows and docking panels.
Combine this with the new .NET Framework 2.0 features such as a better data grid, and I am actually getting very good results and very fast. Looks like .NET is actually delivering its promise: fast time-to-market with a solid framework to support your application.
P.S.: Yes, I know it hogs memory and the CPU with what some native code purists would call needless cycles. But I'm not sure I would be able to do this as fast as I am doing now with either MFC or WTL. Anyway, the core of the code - remote database access - is still native code. The more I think of it, the more I like this combination: native code for the performance bits and managed code for the UI and managing the user environment. A killer!
Combine this with the new .NET Framework 2.0 features such as a better data grid, and I am actually getting very good results and very fast. Looks like .NET is actually delivering its promise: fast time-to-market with a solid framework to support your application.
P.S.: Yes, I know it hogs memory and the CPU with what some native code purists would call needless cycles. But I'm not sure I would be able to do this as fast as I am doing now with either MFC or WTL. Anyway, the core of the code - remote database access - is still native code. The more I think of it, the more I like this combination: native code for the performance bits and managed code for the UI and managing the user environment. A killer!
Wednesday, September 13, 2006
Enumerating devices and services with the Widcomm Bluetooth stack
I've just published an article on enumerating devices and services with the Widcomm Bluetooth stack. You can find it here.
Data Port Wizard crack
Today I noticed some interesting entries in my site's log coming from Google: people searching for a crack for Data Port Wizard. This is quite flattering indeed for a product in its second year. But I believe this is also the side effect of the lack of tool support for SQL Everywhere.
Let's see if I can find a crack for this product myself (hehehe).
Let's see if I can find a crack for this product myself (hehehe).
Tuesday, September 12, 2006
Unified Bluetooth stack access for Windows Mobile
After considering the apparently big differences between the Microsoft and the Widcomm Bluetooth stacks, I found out that there is a way to make them work under a similar API. This is especially useful for Compact Framework developers although some native developers may also benefit from a simple C type API.
The Widcomm API is oriented to C++ developers and exposes itself as a set of C++ classes that are supposed to be consumed either as-is or derived in your application. Exposing this type of API to a .NET CF developer is nothing short of impossibe unless a C layer is developed to consume the Widcomm stack while exposing a set of simple functions.
While I was writing this piece of code, I found out that the Microsoft stack could also be subject to the same treatment. So my idea was to produce two DLL files with exactly the same function exports, one for the Widcomm stack and the other for the Microsoft stack. The obvious advantage of this is that now a .NET CF application can consume the existing Bluetooth stack without having to consider the differences between the Microsoft and the Widcomm stack.
I have to say that this was a very interesting learning project, thanks to Peter Foot's help. The resulting code will be published under a series of articles and, time permitting, I will try to integrate the code in Peter's own 32feet.NET project.
The Widcomm API is oriented to C++ developers and exposes itself as a set of C++ classes that are supposed to be consumed either as-is or derived in your application. Exposing this type of API to a .NET CF developer is nothing short of impossibe unless a C layer is developed to consume the Widcomm stack while exposing a set of simple functions.
While I was writing this piece of code, I found out that the Microsoft stack could also be subject to the same treatment. So my idea was to produce two DLL files with exactly the same function exports, one for the Widcomm stack and the other for the Microsoft stack. The obvious advantage of this is that now a .NET CF application can consume the existing Bluetooth stack without having to consider the differences between the Microsoft and the Widcomm stack.
I have to say that this was a very interesting learning project, thanks to Peter Foot's help. The resulting code will be published under a series of articles and, time permitting, I will try to integrate the code in Peter's own 32feet.NET project.
Subscribe to:
Posts (Atom)