Paul,
Have you been able to play with any early releases of PB-Win Version 10?
How will it effect FF3 ?
The PowerBasic Gazette I just received lists alot of new and powerful features. (Hopefully no conflicts with the current FF)
Marty,
There is no PB's special policy for third party addon providers, i think Paul will discover it at the same time you will get it ;)
...
I haven't gotten PB 10 yet but I will as soon as I can. I also wondering how it will effect FF3. Seems to me it will make Paul's life simpler in the long run. I bet he will now be able to do a lot more cool things. There are many cool neat things listed in the PB gazette and I can't wait to dig in. Its another $200, $99 ea for PB 7 SQL tools but I know it will but I know it will be worth it.
Maybe Paul can fill us in on what effects it will have on FF3 if any.
Merry Christmas
Doug
If you use the currently available headers (mine or the PB ones) and don't use the new features, it won't affect in anything.
If Paul wants to take advantage of the new features, such native unicode support, and I bet he will want it, then some small changes in the generated code will be needed. I will help Paul to do it if needed.
The problems will come if he wants to support both older compilers and the new features of the new ones. If I were Paul I will keep FireFly 3 as it is and write FireFly 4 with the needed changes. His life will be much easier, without having to move declares from this to that, writing each function in a separate file to avoid bloat (with dead code removal this is no longer needed), etc.
I'm ready. The new version of my Windows API Headers allows to work with ansi or unicode transparently just by defining %UNICODE = 1 or not, but as they use the new WSTRING and WSTRINGZ data types, can't be used with older compilers.
If a FF4 is what it takes then I'm all for it.
Doug
Quote from: Jim Dunn on December 24, 2010, 02:01:51 PM
Also, could someone compare SQLITENING with their new "SQL Tools Version 3 that needs no DLLs"???
I like the sound of "no DLLs"... but wonder how it compares to SQLITE???
No DLLs is no problem for SQLitening either since Fred gives us the source code. You can easily use the code as include file with a minimum of changes. Like this you have the SQLitening Client functionality in your exe file. (You still might need zLib.dll though. See SQLitening helpfile under Project Files.)
Attached is a little sample project for a NoDll client application using SQLitening. (You need the sample.db3 provided by Fred Meier in the SQLitening package.)
Note that I renamed the original .Bas files to .Inc. The only differences in these files are that I removed the compiler directives, some double equates, and the EXPORT statements. I had not made any changes to SQLiteningAuxRuts yet.
The SQLitening Server needs Zlib.dll, on the client side it is only needed if you are using compression in local mode.
That cuts it down to sqlite3.dll which is already present on most systems.
What I like about SQLitening is the ease of use, the ease of setting up and configuring a client server system. Syimply said - as you might notice - I am a SQLitening fan!
I can't say anything about SQL Tools because I have never used them.
QuoteI can't say anything about SQL Tools because I have never used them.
It's fairly interesting if one have to deal with Access â€" and MS SQL when one grows past Access' limitations. Not everyone have the luxury of being able to choose the data source.
Hi Haakon,
sure - depends of course on the type of databases you need to access. SQL Tools gives you more options here. But if you are in a closed environment without need to access other database types SQLitening is a wonderful tool.
I am not involved in any PB10 testing. I have no idea how it will impact FF3 - we'll have to wait and see until I purchase the upgrade in a few weeks.
Some of the announced features sound interesting. I love how PB have now implemented static link libraries after shitting all over that idea for years. I guess enough people must have requested it and they relented to the demands finally. The Boss man will be happy to finally be able to link his EZEE engine.
I figured that they would have addressed the idea of having a container for visual ActiveX controls. Maybe they have but are holding that information back. Right now, we are using Joe's wonderful container control.
Maybe a new IDE and Debugger that brings us into line with 2010 standards would be nice too. Actually, I think that I will hold off and eventually use Jose's new editor that he is working on. Too bad that PB doesn't open up the Debugger file format so we can create a better debugger ourselves.
Oh, yes, and complete implementation of forward referencing would be beneficial for FF3 so I wouldn't have to collect all declarations, globals, types, classes, macros, etc... and assemble them in the _DECLARES file.
Merry Christmas everyone! Turkey dinner in less than two hours from now. :)
Quote from: Jose Roca on December 24, 2010, 06:52:36 PM
The problems will come if he wants to support both older compilers and the new features of the new ones. If I were Paul I will keep FireFly 3 as it is and write FireFly 4 with the needed changes.
Yes, that does sound like the best approach. Supporting legacy compilers is always a problem. Maybe FF4 is a good idea for PB10 only support.
If you drop support for older compilers, adding unicode support is easy. Just define %UNICODE = 1 before any #INCLUDE and use WSTRING instead of STRING, and WSTRINGZ instead of ASCIIZ, and a couple of minor changes more. Otherwise, you will need to have paths for four sets of include files -two for mine, and two for PB-, since older compilers can't use the new ones.
It's time to take advantage of the new features and not be constrained by legacy compilers. Current uers can use FF3 for existing applications and FF4 for new ones.
IMO static libraries are mainly useful to people that have code to hide, and very cumbersome to make if you want to avoid bloat. Include files are more versatile, since dead code removal is automatic and you can also make use of conditional compilation.
My two most wanted features were native unicode support and dead code removal, and both have been implemented perfectly, and I have tested them very thoroughly. Unicode is very important to people that doesn't use English and can open new markets for the compiler. It is also very important to use COM: no more ACODE$/UCODE$ and no more workarounds to deal with methods that use null-terminated unicode strings (unicode ASCIIZ strings). Dead code removal has allowed me to get rid of the macro functions (no more %USEMACROS) previously used to avoid bloat. For example, I have written an include file with wrapper functions for each ane every one OpenGL extensions (1,720, no less), and only the ones called will be incorporated in your code. Now you can use OpenGL extensions with PB more easily than with C. I have also one for ODBC with hundreds of functions and I will write more and also classes.
QuoteThe Boss man will be happy to finally be able to link his EZEE engine.
Another feature to drown in his long list with gibberish.
QuoteMaybe a new IDE and Debugger that brings us into line with 2010 standards would be nice too.
Nah. when it comes to making applications with/for their compiler that incorporates a UI and sensible user logic, they just don't seem to get a grasp on reality, it's needs and desires. I bought their best attempt and shortly thereafter it was archived and never installed again.
Paul, I would be very open to buy an upgrade. This seems to be a major change. Your work on it deserves a payment. I know its a year out probably but it would be welcome. It sounds like there are some very cool things you could do.
Doug
Yes, I too would purchase an upgrade.
Me too
Yep - I agree!
Me too
Me 3
Count me in
Add me to the list
At this rate, I should release a new FireFly every two weeks!!! I'd be rich!!! ha ha ha ha :D
Seriously, thanks guys. Your support for FireFly is amazing and I really appreciate it. We will have a PB10 compatible FireFly after I get my hands on the new compiler.
Old code will compile with the new compiler using old headers. Maybe a couple of changes will be needed because a conflict with a new keyword or the use of DIM <variable name> (1:10) AS <variable type> because now you have to se 1 TO 10 instead of 1:10. But nothing of importance.
If you use the upcoming new include files, all the functions, methods and properties that need unicode string parameters or return unicode strings must be changed. No more use of UCODE$/ACODE$, as conversion is done automatically. Parameters that needed an unicode string, were declared AS DWORD, the variables were declared AS STRING and converted to unicode with UCODE$, and passed using STRPTR. Now, these parameters will be declared as WSTRING or WSTRINGZ, depending if the method wants an OLE string or a null-terminated unicode string (an ASCIIZ string with embeded nulls).
My new editor is unicode aware and, optionally, allows the use of unicode in comments and string literals (WYSIWYG). As the compiler only works with ansi files, unicode support in the editor is done using UTF-8 encoding.
William Burns made the ultimate mistake on the PB forum -
he expressed his opinion. Refer to http://www.powerbasic.com/support/pbforums/showthread.php?t=45796&page=3 and the subsequent posts by Zale inferring that William is purposely misleading customers.
Quote
Well, the fact is that our plan is to release information on our schedule. We won't engage in any arguments, and we sincerely hope that all of our friends here will simply review our information with care.
If you find it necessary to publish flawed assumptions about our products, it is indeed unfortunate. I hope you'll reconsider.
Best regards,
Bob Zale
PowerBASIC Inc.
Didn't seem to me that William was "arguing". It also appears that William is now not considered a "friend" and that William took it upon himself to "find it necessary to publish flawed assumptions".
Give me a break.
$20 bet that Zale also sent William a private message looking for a groveling apology.
Zale should stick to writing compilers and leave public relations to someone with more experience, tact, and genuine concern for his "friends".
Geez Paul... Did the Bruins lose last night? :-*
You're right of course... I didn't think anything William said was out of place, he was only stating that:
"Given the published information... he wouldn't pre-order".
His current procedures were working, so why hurry to change.
Quote from: TechSupport on January 01, 2011, 09:59:34 PM
Zale should stick to writing compilers and leave public relations to someone with more experience, tact, and genuine concern for his "friends".
I certainly agree with this, Paul :D He tends to want to debate anyone that speaks their opinion :D
Gary
Quote from: TechSupport on January 01, 2011, 09:59:34 PM$20 bet that Zale also sent William a private message looking for a groveling apology.
Sounds like you speak out of experience ... ;)
I don't know enough, not even close but I hope that in some degree PB 10 will allow FF3 (Paul) to come up with some real debugging.
It's wishful thinking since I think it really has nothing to do with Pb's compiler but more to do with PB not opening up their debugger. I'm very surprised that some very good PB programmer hasn't come up with a good debugger.
I see the lack of good debugging outside (even inside) Pb to be its weakest point.
Doug
Quote from: Jim Dunn on December 24, 2010, 02:00:14 PM
Did anyone notice, they now have "STATIC LIB SUPPORT"?!?
I thought this was a "no no"... listening to everyone say "we can't have static libs; whose lib format would we use"?
So, now they have it; I wonder which format they used?
Their own format, as expected. The issue was never that there couldn't be static libraries per se; the issue was with those people who were asking for the ability to link to Microsoft's object files and libraries and I posted a few messages on the PB forums explaining in some detail why that simply wasn't realistic.
So you'll have static link libraries, but they'll only be useable by and for PowerBasic. If you want any kind of language interoperability, you're still looking at using DLLs.
Man, I'm away for a while and miss another fun thread. I did notice the BZ rant over in the PB forums, but don't post much there anymore. The new version does look interesting. I must have ticked Bob off last Beta when they screwed up the File Open Dialog stuff by not including the fix from 8 years ago in the inc files until the very end...the new PB internal was later fixed when it failed since they again forgot how the inc file needed fixed. He removed all my comments on it then and I didn't get invited to the Beta party this time around. Sounds like Jose is still in though. I'm more curious about the resource compiler stuff than the things they finally added. I'm wondering if they finally included the ability for the new resources that fail in the old one needing me to use my VS RC and if they support all types. I often use ANI Icons which I bug Paul with all the time too and are often forgotten. Along with supporting raw data and the XP/Vista manifests, etc. With support for strings like they have now, being able to have easy string tables to support different languages integrated right in and easy to use would be nice too. Built in commands for resource handling would be a plus too since they are part of the code now being able to read/write would fit right in.
I didn't think that PB would charge credit cards until the product shipped. My card was charged on the day I ordered it (Jan 10). Maybe I missed a check button option somewhere on the order form? Has everyone else here been charged already?
I was charged
Doug
In the US at least, the Federal Trade Commission Mail/Telephone Order Rule (which applies to Internet sales) requires that a company should ship your order within the time stated in its ad. If no time is promised, the company should ship your order within 30 days after receiving it.
If the company is unable to ship within the promised time, they must give you an “option notice.†This notice gives you the choice of agreeing to the delay or canceling your order and receiving a prompt refund.
We shall see.
Dennis
I was charged also. There were a few post from those across the big pond that wanted to be charged before the end of the year because their country allowed $400 in internet purchases a year without duties being charged (or something like that). I was a little surprised when I seen that I had been charged before the product was shipping. This was the way they have always done it in the past. Bob told someone if they wanted to be charged, to put a comment in the comment box. I left it blank, but was still charged. Its not a big deal, just not the way they have been doing it. ;)
Gary
Hi Gary - yes, that was my understanding as well. I remembering reading that post on the PB Forum, that's why I was a little surprised to see the charge on my account already.
The more time that passes, the more it resembles... vaporware.
Oh well. I hope I have it before I have to start paying interest
charges. That will occur in about 10 days.
I've experienced that goods where not shipped on the day my card was charged â€" something I recall is one of the requirements for being able to accept Visa transactions.
After sending them a mail (I allowed them some time/days to ship first) that I would not accept this and wanted to cancel the order â€" something they declined. I then contacted my local bank about the disagreement and supplied them with the correspondence so that they had some documentation to supply Visa with.
After a waiting period, Visa then refunded my money â€" no more questions asked.
I haven't been keeping up over at PB much, but does anyone know if there is a keyword or something to add that makes the compiler included unused code no matter what and maybe even something to mark code it may always keep as safe to remove? And/Or does it always include code in classes/DLL files that would be used by something else? In some cases you may want it to clean things like WinAPI stuff not used, but keep code in your DLL/Class that may not be used or may look like it isn't used.
If a function is exported or declared as common, isn't removed. If a class is declared as COM, it is kept intact. Code is ony removed when it is dead, i.e. nobody references it and it is not exported.
DLLs and SLLs are different animals.
For me the code removal, must be done at Link time, not compile time.
Quote from: Patrice Terrier on January 17, 2011, 03:23:55 PM
For me the code removal, must be done at Link time, not compile time.
Based just on what I've read, it sounds like they're doing it during the complation phase by building a call graph and then eliminating those functions that aren't being called or exported. It's possible that they are doing COMDAT elimination/folding as well, but they haven't really given the implementation specifics.
What happened to the update????
It's been almost a month and a half since the pre-ordering opened. Weird that it is taking this long. I would have thought that it would have been a couple of weeks or so or a month at most. Hopefully it won't be too much longer. It all seems a little anti-climatic now.
I think they put already a lot of pressure on themselves with this new pre-order policy.
...
Dead-code-removal will be done at compile time of the SLL, not at link time of the final EXE.
This means you could still have unused code into the final EXE, if your are not using heavy SLL granularity.
...
The number that counts is the number of PBer's that will buy such compiler and I think that it is still small, since most seem to be using XP. I myself, I'm using Windows 7 32-bit.
Kind of rethoric, i have experienced myself that some power of two numbers could be a very sensitive subject ;)
...
PowerBasic is trying to keep up with Google. This is Bob Zales' version of "computing in the cloud".
QuoteThe number that counts is the number of PBer's that will buy such compiler and I think that it is still small, since most seem to be using XP. I myself, I'm using Windows 7 32-bit.
You're thinking of "the" 64-bit PB compiler?!
Even though I'm on 64-bit Windows on all my 3 computers in general use, I don't really see 32-bit applications being an issue. Some applications ought to be 64-bit to utilize memory better - like Photoshop, Lightroom and other graphic intensive / memory hungry applications. And drivers off course ...
Except from that I've only experienced problems with a few utilities that are supposed to add some items to the context sensitive menus in Explorer. The menu items just don't shop up unless explorer is started in 32-bit mode, due to the lack of possibility to have executables/libraries "cross-talk".
So I guess you're quite right that the need for a 64-bit compiler probably ain't that large. But I think more people than those in need, would find it useful by time.
And for those who can't wait, then you can move to Visual Studio 2010, and start learning C++ :)
I take it that PB has not started to ship version 10.
This will be the last time I pre-order PB. I don't
mind waiting a month, but 2 months maybe more?
That's asking to much. Bob's credibility has now
been tarnish IMHO.
:(
The way to hell is paved with good intentions... I doubt we'll see the option to pre-order again.
Marc
Good intentions - yes! That sometimes happens to me too, that I promise a customer a piece of software within two weeks. Then you run into some sort of problem, and the two weeks become two months. I have become extremely carefull with such promises.
I think that probably happened at PB.
Usually nobody would mind - as long you did not collect morey for it yet. I think they should at least send some sort of notification to their customers, expecially those that have paid already!
I've got a funny feeling in my stomach. I cannot reach the PB website anymore since a half an hour.
Correction:
OK - They are running again.
There was some interest in getting PB10 on last year's balance sheet as well. It doesn't apply to me, but I don't have any problems waiting for PB10 and the best part is once I get it ... it's already paid for :D
Quote from: Rolf Brandt on February 17, 2011, 05:51:16 AM
I've got a funny feeling in my stomach. I cannot reach the PB website anymore since a half an hour.
Correction:
OK - They are running again.
http://downforeveryoneorjustme.com/
Quote from: Haakon Birkeland on February 16, 2011, 09:59:29 AM
So I guess you're quite right that the need for a 64-bit compiler probably ain't that large. But I think more people than those in need, would find it useful by time.
For stand-alone applications on desktop computers, that's true. For libraries, components, plug-ins and so on, 64-bit support is more of an issue. For example, if you developed a inproc COM component for use with Office, it won't work with the 64-bit version of Office 2010. Another consideration is the requirement for only 64-bit applications because the admins are disabling the WoW64 subsystem to reduce the threat surface of their servers.
Unfortunately, the migration to 64-bit may be more painful because the language and documentation really encouraged this idea that pointers and handles were DWORDs and that DWORDs could be treated as pointers and handles. That is going to bite developers in a huge way if/when a 64-bit version of PowerBasic is released and they try to migrate legacy applications.
I'm actually kind of surprised that they haven't introduced a polymorphic data type like DWORD_PTR, updated all of their function declarations and encouraged developers to start using it rather than just DWORD so they'll be able to start preparing their code for 64-bit platforms.
QuoteI'm actually kind of surprised that they haven't introduced a polymorphic data type like DWORD_PTR
One of the language i am working with, is using SYSINTEGER that is 4 bytes on 32-bit and 8 bytes on 64-bit.
QuoteFor libraries, components, plug-ins and so on, 64-bit support is more of an issue.
So true!
Has anybody heard anything regarding the estimated release?
Prepaid, Two months and no information from Powerbasic. I cannot understand what they are thinking.
It sure is taking a long time to get our hands on PB10. Wouldn't be so bad if they stuck to the statement that they would not charge the credit cards unless asked to do so by the customer - but they didn't do that. I can't imagine me participating in this pre-order thing again in the future.
I agree. Perhaps I missed something but I was expecting the charges to appear only after they shipped. Even though I'm not presently interested in canceling my order or requesting a refund, this sequence of events has been surprising. -- tom
I guess the "stay tuned.....January is going to be exciting" kinda fell through the cracks.....as a matter of fact, I haven't seen anything too exciting about February :-\ Several of the new features sound interesting, but I am not too keen on the way PB has done things this time around. Maybe they didn't mean this January :'(
Oh well, I guess it will be here sometime.....I hope.
Gary
At least they have offered people to "just ask" for a refund if the wait gets to unbearable.
PowerVivian needs to put away her Christmas decorations. :)
Quote from: Haakon Birkeland on February 25, 2011, 07:47:00 AM
At least they have offered people to "just ask" for a refund if the wait gets to unbearable.
I am gonna continue to wait and not request a refund, but, I had sure hoped that by the end of January, we would have seen something. I know things come up and if they would come out and admit....hey we ran into some issues and its gonna be end of March or whatever, I would be fine with that. Right now they are just keeping us in the dark and not telling us anything and you definitely don't want to tick off the leader by saying the wrong thing :-\
Gary
Gary
I'm the type of person that "dies on the inside" when someone is up on stage, trying their best, but sounding terrible.
That's where I am with Bob and PB10.
I keep hoping that maybe he'll have something up his sleeve... like "SURPRISE, WE CAN COMPILE 64-BIT APPS" or something.
But day after day, it doesn't happen.
And so, I keep dying on the inside.
True Jim, that's the sort of thing that keeps us going and going. Take it away and we wither.
Regarding the delay and Vivian's outfit, I guess we just have to say that this time â€" Christmas came late, very late ...
From the PB Forums:
QuoteWhile we haven't quoted a specific date for the new compilers, we have mentioned some approximations. While we still have a few minor items to resolve, I think the word imminent is a fair descriptor. Please stay tuned. You will not be disappointed.
Best regards,
Bob Zale
PowerBASIC Inc.
http://www.powerbasic.com/support/pbforums/showthread.php?t=46444&page=17
Oh, yeah! â€" http://powerbasic.com/support/pbforums/showpost.php?p=369896&postcount=272
I am no longer excited about this new version. Over two months waiting after having being charged for the product has certainly taken any excitement away for me. I just want to get this thing so I can build a new FireFly for it and then move on with life. The PB10 drama is an epic fail from my perspective.
I send an email to sales@powerbasic.com a week ago and was told:
Hello--
Thanks for writing. The PowerBASIC products you ordered should be
available within the next 10 days or so. We tried to make it very
clear that orders placed now are a pre-order, to avoid all the usual
delays when they are released.
It was explained in our email announcement and on our web site
announcement. Also, both the order form and the acknowledgement show
it as a pre-order. If that poses a problem for you, we can return
your deposit. However, there would likely be a delay when it's
replaced later. The choice is yours. Please let me know?
Tim Robbins
PowerBASIC Inc.
.......................
Well by Friday it will have been 12 days.
Has anyone here requested a refund? Was it process quickly? Or, did you also have to wait 3 months to get that as well?
Has PowerBasic chnged their mind about vaporware? Or has the diffination of vaporware been change when I wasn't watching?
I'm really torn about this. I pre-paid (pre-ordered) on Day 1, when they announced it.
I ordered both the PB10 and the SQLTOOLS3. It was a *LOT* of money. I didn't realize it was a lot, because of the excitement, but now...
Now I'm considering canceling, and moving to PureBasic.
I'm not *that* deep into PowerBASIC, and although I see a learning curve, I also see cross-platform support...
If only I could talk Paul into reconsidering his "FireFly for PureBasic" project...
(no pressure Paul, well, not much)
Upgrades are most always painfull.... you have to Read...read...read.... and at my age..do it again. :-)
But hopefully the 'new' features may make it all worth while and allow you to do easily what was more difficult before.
As a hobby programmer ( like a back yard mechanic )... I do this for various reasons... save money, learn how to do something I've never done before... and even just to keep the old noggin working... ( thinking in computerese gets more difficult as I get older ) ...
I don't go out and buy everthing that comes along execpt with my programming.. ( it's cheaper than say flying ) and I have used.. EZGUI ( all versions ), PwrDev, Firefly, Winlift... each having their own strengths and uses... and who knows what the future brings?
I like the fact that it's already paid for... but I have to admit... it would have been nice if we could have gotten a beta copy of the documents for our trouble...
I
Preordering should have been connected to a rebate. That would have been more bearable.
Recent comment about FireFly3 and PB10 compatibility on the PowerBASIC forum (attached).
And here is the link to the post:
http://www.powerbasic.com/support/pbforums/showpost.php?p=370519&postcount=12
or to the thread:
http://www.powerbasic.com/support/pbforums/showthread.php?t=46703
Paul ???
As long as you will use the new Jose Roca's include files, the main problem you will encounter is with new reserved words.
...
I hope that it works well with FF. I will know more once I get my hands on PB10.
Existing code that uses my headers will work without changes with PB10 and my new headers except these that use calls to unicode functions or COM interfaces. These will continue to work with PB10 without changes using the current headers, but will need changes to work with PB10 and the new headers.
The reason is that because there was not native unicode support in PB9 we had to use the workaround of declaring the parameter as BYVAL DWORD, use a dynamic string and UCODE$ and pass a pointer to the string content using STRPTR. With PB10 and the new headers, these parameters are now declared as WSTRING or WSTRINGZ, as appropriate, and you no longer have to use UCODE$/ACODE$.
Regarding the API functions, these are the ones that will need a change: PtInRect, MenuItemFromPoint, WindowFromPoint, ChildWindowFromPointEx, WindowFromPoint, MonitorFromPoint, RealChildWindowFromPoint, LBItemFromPt, DragDetect.
All of these have a parameter that is a POINT structure passed by value. As very old versions of the compiler could not pass structures by value, they used two long parameters, x and y. I also used two long parameters in my headers to avoid conflicts with the PB headers, but this is not longer the case with the new PB headers. To make the change as painless as possible, I'm providing alternate XY functions, so you only have to change slightly the name of the function if you prefer to continue passing longs.
DECLARE FUNCTION PtInRect IMPORT "USER32.DLL" ALIAS "PtInRect" ( _
BYREF lprc AS RECT _ ' __in CONST RECT *lprc
, BYVAL pt AS POINT _ ' __in POINT pt
) AS LONG ' BOOL
' Same as above, but using x, y coordinates
DECLARE FUNCTION PtInRectXY IMPORT "USER32.DLL" ALIAS "PtInRect" ( _
BYREF lprc AS RECT _ ' __in CONST RECT *lprc
, BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
) AS LONG ' BOOL
DECLARE FUNCTION MenuItemFromPoint IMPORT "USER32.DLL" ALIAS "MenuItemFromPoint" ( _
BYVAL hWnd AS DWORD _ ' __in_opt HWND hWnd
, BYVAL hMenu AS DWORD _ ' __in HMENU hMenu
, BYVAL pt AS POINT _ ' __in pt POINT
) AS LONG ' int
' // Same as above, but using x, y coordinates
DECLARE FUNCTION MenuItemFromXY IMPORT "USER32.DLL" ALIAS "MenuItemFromPoint" ( _
BYVAL hWnd AS DWORD _ ' __in_opt HWND hWnd
, BYVAL hMenu AS DWORD _ ' __in HMENU hMenu
, BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
) AS LONG ' int
DECLARE FUNCTION WindowFromPoint IMPORT "USER32.DLL" ALIAS "WindowFromPoint" ( _
BYVAL Point AS POINT _ ' __in POINT Point
) AS DWORD ' HWND
' // Same as above, but using x, y coordinates
DECLARE FUNCTION WindowFromXY IMPORT "USER32.DLL" ALIAS "WindowFromPoint" ( _
BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
) AS DWORD ' HWND
DECLARE FUNCTION ChildWindowFromPointEx IMPORT "USER32.DLL" ALIAS "ChildWindowFromPointEx" ( _
BYVAL hWnd AS DWORD _ ' __in HWND hWnd
, BYVAL pt AS POINT _ ' __in POINT pt
, BYVAL Flags AS DWORD _ ' __in UINT Flags
) AS DWORD ' HWND
' Same as above, but using x, y coordinates
DECLARE FUNCTION ChildWindowFromXYEx IMPORT "USER32.DLL" ALIAS "ChildWindowFromPointEx" ( _
BYVAL hWnd AS DWORD _ ' __in HWND hWnd
, BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
, BYVAL Flags AS DWORD _ ' __in UINT Flags
) AS DWORD ' HWND
DECLARE FUNCTION MonitorFromPoint IMPORT "USER32.DLL" ALIAS "MonitorFromPoint" ( _
BYVAL pt AS POINT _ ' __in POINT pt
, BYVAL dwFlags AS DWORD _ ' __in DWORD dwFlags
) AS DWORD ' HMONITOR
' // Same as above, but using x, y coordinates
DECLARE FUNCTION MonitorFromXY IMPORT "USER32.DLL" ALIAS "MonitorFromPoint" ( _
BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
, BYVAL dwFlags AS DWORD _ ' __in DWORD dwFlags
) AS DWORD ' HMONITOR
DECLARE FUNCTION RealChildWindowFromPoint IMPORT "USER32.DLL" ALIAS "RealChildWindowFromPoint" ( _
BYVAL hwndParent AS DWORD _ ' __in HWND hwndParent
, BYVAL ptParentClientCoords AS POINT _ ' __in POINT ptParentClientCoords
) AS DWORD ' HWND
' // Same as above, but using x, y coordinates
DECLARE FUNCTION RealChildWindowFromXY IMPORT "USER32.DLL" ALIAS "RealChildWindowFromPoint" ( _
BYVAL hwndParent AS DWORD _ ' __in HWND hwndParent
, BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
) AS DWORD ' HWND
DECLARE FUNCTION LBItemFromPt IMPORT "COMCTL32.DLL" ALIAS "LBItemFromPt" ( _
BYVAL hLB AS DWORD _ ' __in HWND hLB
, BYVAL pt AS POINT _ ' __in pt POINT
, BYVAL bAutoScroll AS LONG _ ' __in BOOL bAutoScroll
) AS LONG ' int
' // Same as above but using x, y coordinates
DECLARE FUNCTION LBItemFromXY IMPORT "COMCTL32.DLL" ALIAS "LBItemFromPt" ( _
BYVAL hLB AS DWORD _ ' __in HWND hLB
, BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
, BYVAL bAutoScroll AS LONG _ ' __in BOOL bAutoScroll
) AS LONG ' int
DECLARE FUNCTION DragDetect IMPORT "USER32.DLL" ALIAS "DragDetect" ( _
BYVAL hwnd AS DWORD _ ' __in HWND hwnd
, BYVAL pt AS POINT _ ' __in pt POINT
) AS LONG ' BOOL
' // Same as above, but using x, y coordinates
DECLARE FUNCTION DragDetectXY IMPORT "USER32.DLL" ALIAS "DragDetect" ( _
BYVAL hwnd AS DWORD _ ' __in HWND hwnd
, BYVAL x AS LONG _ ' __in x
, BYVAL y AS LONG _ ' __in y
) AS LONG ' BOOL
There are other changes that don't affect existing code, such the RECT structure, that now is an union to allow the use of rc.nLeft, rc.Left, rc.x, etc.
' // Size = 16 bytes
TYPE OLD_RECT_STRUCT DWORD ' Old PB definition
nLeft AS LONG ' LONG left
nTop AS LONG ' LONG top
nRight AS LONG ' LONG right
nBottom AS LONG ' LONG bottom
END TYPE
' // Size = 16 bytes
TYPE tagRECT DWORD
left AS LONG ' LONG left
top AS LONG ' LONG top
right AS LONG ' LONG right
bottom AS LONG ' LONG bottom
END TYPE
' // GDI+ uses x, y, Width and Height as members instead of Left, Right, Top and Bottom
TYPE GDIP_RECT_STRUCT DWORD
x AS LONG ' LONG x
y AS LONG ' LONG y
Width AS LONG ' LONG Width
Height AS LONG ' LONG Height
END TYPE
' // To allow the use of both nLeft, etc, and Left, etc.
' // Size = 16 bytes
UNION RECT
OLD_RECT_STRUCT
tagRECT
GDIP_RECT_STRUCT
END UNION
The new headers allow to work with unicode transparently just by defining %UNICODE = 1 before #INCLUDEing the headers. For example, if you call RegisterWindowMessage, RegisterWindowMessageA will be called if %UNICODE is not defined (not defined does not mean equal to 0; if you use %UNICODE = 0, then %UNICODE is defined with a value of 0), and RegisterWindowMessageW will be called if %UNICODE is defined (any value, although the usual is to set it to 1).
DECLARE FUNCTION RegisterWindowMessageA IMPORT "USER32.DLL" ALIAS "RegisterWindowMessageA" ( _
BYREF lpString AS ASCIIZ _ ' __in LPCSTR lpString
) AS DWORD ' UINT
DECLARE FUNCTION RegisterWindowMessageW IMPORT "USER32.DLL" ALIAS "RegisterWindowMessageW" ( _
BYREF lpString AS WSTRINGZ _ ' __in LPCWSTR lpString
) AS DWORD ' UINT
#IF %DEF(%UNICODE)
MACRO RegisterWindowMessage = RegisterWindowMessageW
#ELSE
MACRO RegisterWindowMessage = RegisterWindowMessageA
#ENDIF
You can also call RegisterWindowMessageA or RegisterWindowMessageW individually.
This SDK skeleton will work either as ansi or unicode just commenting or uncommenting the %UNICODE constant:
#COMPILE EXE
#DIM ALL
'%UNICODE = 1
' // Include files for external files
#INCLUDE ONCE "windows.inc"
' ========================================================================================
' Main
' ========================================================================================
FUNCTION WINMAIN (BYVAL hInstance AS DWORD, BYVAL hPrevInstance AS DWORD, BYVAL lpszCmdLine AS ASCIIZ PTR, BYVAL nCmdShow AS LONG) AS LONG
LOCAL hwndMain AS DWORD
LOCAL hFont AS DWORD
LOCAL wcex AS WNDCLASSEX
#IF %DEF(%UNICODE)
LOCAL szClassName AS WSTRINGZ * 80
LOCAL szCaption AS WSTRINGZ * 255
#ELSE
LOCAL szClassName AS ASCIIZ * 80
LOCAL szCaption AS ASCIIZ * 255
#ENDIF
' // Default font
hFont = GetStockObject(%DEFAULT_GUI_FONT)
' // Register the window class
szClassName = "MyClassName"
wcex.cbSize = SIZEOF(wcex)
wcex.style = %CS_DBLCLKS OR %CS_HREDRAW OR %CS_VREDRAW
wcex.lpfnWndProc = CODEPTR(WindowProc)
wcex.cbClsExtra = 0
wcex.cbWndExtra = 0
wcex.hInstance = hInstance
wcex.hCursor = LoadCursor (%NULL, BYVAL %IDC_ARROW)
wcex.hbrBackground = %COLOR_3DFACE + 1
wcex.lpszMenuName = %NULL
wcex.lpszClassName = VARPTR(szClassName)
wcex.hIcon = LoadIcon (%NULL, BYVAL %IDI_APPLICATION) ' // Sample, if resource icon: LoadIcon(hInst, "APPICON")
wcex.hIconSm = LoadIcon (%NULL, BYVAL %IDI_APPLICATION) ' // Remember to set small icon too..
RegisterClassEx wcex
' // Window caption
szCaption = "Generic SDK Program"
' Create a window using the registered class
hwndMain = CreateWindowEx(%WS_EX_CONTROLPARENT, _ ' extended style
szClassName, _ ' window class name
szCaption, _ ' window caption
%WS_OVERLAPPEDWINDOW OR _
%WS_CLIPCHILDREN, _ ' window style
%CW_USEDEFAULT, _ ' initial x position
%CW_USEDEFAULT, _ ' initial y position
%CW_USEDEFAULT, _ ' initial x nSize
%CW_USEDEFAULT, _ ' initial y nSize
%NULL, _ ' parent window handle
0, _ ' window menu handle
hInstance, _ ' program instance handle
BYVAL %NULL) ' creation parameters
' // Show the window
ShowWindow hwndMain, nCmdShow
UpdateWindow hwndMain
' // Message handler loop
LOCAL uMsg AS tagMsg
WHILE GetMessage(uMsg, %NULL, 0, 0)
IF IsDialogMessage(hwndMain, uMsg) = 0 THEN
TranslateMessage uMsg
DispatchMessage uMsg
END IF
WEND
FUNCTION = uMsg.wParam
END FUNCTION
' ========================================================================================
' ========================================================================================
' Main callback function.
' ========================================================================================
FUNCTION WindowProc (BYVAL hwnd AS DWORD, BYVAL uMsg AS DWORD, BYVAL wParam AS DWORD, BYVAL lParam AS LONG) AS LONG
' // Process window mesages
SELECT CASE uMsg
CASE %WM_COMMAND
SELECT CASE LO(WORD, wParam)
CASE %IDCANCEL
' // If the Escape key has been pressed...
IF HI(WORD, wParam) = %BN_CLICKED THEN
' // ... close the application by sending a WM_CLOSE message
SendMessage hwnd, %WM_CLOSE, 0, 0
EXIT FUNCTION
END IF
END SELECT
CASE %WM_DESTROY
' // End the application
PostQuitMessage 0
EXIT FUNCTION
END SELECT
' // Pass unprocessed messages to Windows
FUNCTION = DefWindowProc(hwnd, uMsg, wParam, lParam)
END FUNCTION
' ========================================================================================
As you can see, the only visible difference is:
#IF %DEF(%UNICODE)
LOCAL szClassName AS WSTRINGZ * 80
LOCAL szCaption AS WSTRINGZ * 255
#ELSE
LOCAL szClassName AS ASCIIZ * 80
LOCAL szCaption AS ASCIIZ * 255
#ENDIF
but if %UNICODE is defined, it will call RegisterClassExW, CreateWindowExW, DefWindowProcW, SendMessageW, else it will call RegisterClassExA, CreateWindowExA, DefWindowProcA, SendMessageA.