PB9 Major Problems

[Jeff Radue]

Hello folks, I finally broke down and purchased PB9 after years of using 7.04 with no problems. Today I installed PB9 and tried recompiling one of my major projects. Except for a few declaration changes, recompiling went smooth. The code is primarily SDK. However, when I run the compiled program, it is slow, choppy and crashes frequently. I also noticed that a separate DLL I use with the program does not load it's resource file. Instead it is using the resource from the main exe. This is very strange and a bit frustrating. My programs ran like a fine tuned machine in 7.04, now I can do nothing!

Anyone have a suggestion, or maybe experienced similar problems?

[Graham McPhee]

Not come across any similar problems so far. Im sure if you pass examples of your code to support they will investigate for you.

[Marco Pontello]

Just a blind shot but, seeing that you are moving from PB 7.xx, skipping version 8, maybe this can be of some interest:

http://www.powerbasic.com/support/pbforums/showthread.php?t=35253

Bye!

[Michael Mattias]

I just ported the EDI PAl(tm) software from 7.0.3 directly to 9.0.0 and so far have seen zero problems except for the THREAD CREATE... SUSPEND and one call not recognizing a parameter correctly bugs in 9.0.0 .. that is, way fewer problems than I had thought I might have encountered.

Once compiled however, runs smooth and free and easy. (Even tranparently uses the 7x-compiled kit DLLs, which do not change for this release of the software).

MCM

[Jeff Radue]

Thanks for the replies guys. I tried redownloading the package and reinstalling thinking the install package may be corrupt. No luck. Also, it appears I no longer can fix the problem by going back to 7.04. I tried recompiling with 7.04 and the same thing. I am not sure what to do now.
I am really baffled because I have had good results with PB, but something is wrong here.

[Ian Cairns]

silly suggestion

Jeff, when you "went back" to 7.04, did you recompile from the originals (including reproducing any associated DLL's), or from the updated (altered) programs? If you recompiled using the "updated" ones in 7.04, then something in your code where the changes occured might be responsible.

best wishes, Ian

[Jeff Radue]

Well the problem is mostly solved. See below.

http://www.powerbasic.com/support/pbforums/showthread.php?t=38661

Bob is right. There are some serious side effects to using this.

Thanks to all for your replies......

[Bob Zale]

Let's clarify this. As documented by PowerBASIC, a single equate %PB_EXE can return an incorrect value in some cases. For that reason, you should avoid using that single equate until the next free update is released.

This will not prevent you from compiling accurately with the current version as long as you replace the equate with a replacement which has a correct value. This will not prevent you from going back and recompiling with a previous version, achieving precisely the same, accurate results, as always. This will not make your programs run slow and choppy.

This is a single equate which may return a wrong value. Please don't allow an emotional post to give you a misleading impression of a very fine compiler. Thanks!

Bob Zale
PowerBASIC Inc.

[Jeff Radue]

Bob there was no intent on my part to "slight" PBWIN. I have purchase many of your compilers for more than a decade (since PowerBasic 1) and I am very happy with them. However, the fact is when I commented out the %PB_EXE equate from conditional compilation, it clear up some very strange behavior for the most part. This includes having the DLL's fail to load their internal resources and default to the main exe resources. I have never seen that behavior before. My intent is to inform you, and the rest of the community of potential issues so they can be addressed.

[Bob Zale]

Jeff, I understand your emotional response. That's fine by me. You were surprised, and jumped to some conclusions. We simply needed to bring some clarity and accuracy to the descriptions.

If you use an equate which returns a wrong value (such as this case), your program may not compile in the way you intended. There will be unintended side effects. But, the notion that you will be prevented from going back and recompiling later is a substantial "stretch". It is not true.

If you use the equate %pb_exe, no damage will be done to your source code. Nothing will prevent you from recompiling 10 seconds later or 10 months later.

PowerBASIC recommends that you avoid the use of this equate right now. A free update will be available very soon which will address it, and offer additional improvements, too. If anyone finds this to be even a tiny burden, just drop a note to [email protected] and you'll get you an instant solution.

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

Jeff, when you "went back" to 7.04, did you recompile from the originals (including reproducing any associated DLL's),

As per above, if the DLLs don't change, you don't have to recompile them.

A DLL is a DLL is a DLL.

MCM

[Jeff Radue]

Actually, I erased all the DLL's and recompiiled with 7.04 and it still did not work. A very strange thing, as this really should not have happened. Perhaps I had some "cross contamination" since I have both 7.04 and 9.00 installed on the same machine. The WinAPI files are older and somewhat customized for my 7.04 installation (but they still exist in my 7.04 folder). I may try to recompile a 7.04 version at some time, but it is pointless now since I have 9.00 substaintially working.

One thing I noticed is that none of my custom control would work when I used the Control Add statement. I had to go back into my code and change to straight SDK (CreatedWindowEx statements). This change screwed up the control position because of the units. I am not sure what the difference is in 9.0, but I am would be interested if someone else has a suggestion. As I said previously, the existing code worked fine in 7.04. Perhaps I need to keep a little more updated in the future.

I appreciate all the input from you folks, this is a great forum!

[Bob Zale]

Jeff--

You are posting misinformation which is substantially misleading. If you insist upon continuing in this way, please post sample code which fails in a way other than the immediate use of %pb_exe.

If you need help, please contact [email protected] and they will give you prompt and free assistance. This sort of misinformation helps no one. Please re-think your strategy?

Bob Zale
PowerBASIC Inc.

[Jeff Radue]

Bob, I am sorry you feel I am posting misinformation. I fact all I am doing is mentioning issues that I am having with the conversion. I in no way am blaming PBWin. It may simply be errors in my coding. The issue with the custom controls is not related to %PB_EXE since I am no longer using that equate anywhere in my code.

In 7.04 this worked:

 
InitGraphWinCtrl hInst&
  CONTROL ADD "TGGRAPH", hWnd, CtrlId, "", vLeft, vTop, vWidth, vHeight, _
  %WS_VISIBLE OR %WS_CHILD OR %DS_CONTROL, %WS_EX_CLIENTEDGE
  CONTROL HANDLE hWnd, CtrlId TO hwin

In 9.00 it fails to create a window. So I use:

 
d&        = InitGraphWinCtrl(hInst&)
  hwin      = CreateWindowEx(flag&,"TGGRAPH","",%WS_VISIBLE OR %WS_CHILD OR %DS_CONTROL,vLeft,vTop,vWidth, vHeight,hWnd,byval %NULL,hInst&,BYVAL %NULL)                
  d         = SetWindowLong(hwin,%GWL_ID,CtrlId)

In both cases the InitGraphWinCtrl (RegisterClassEx) function works fine and returns a value. However in 9.00 the Control Add statement returns zero.

If you feel this discussion belongs in another venue then fine. But I have had the most success in solving programming issues by presenting them to the community.

[Michael Mattias]

The WinAPI files are older and somewhat customized for my 7.04 installation (but they still exist in my 7.04 folder)

Frankly, over the years I have had more problems with the header files than with the compiler itself when "up-versioning."

Also of note...

- I had problems with the resource compiler shipped with 8x. I just used the one from 7x, worked fine. I have not yet worked a lot with the resource compiler shipped with 9x , but I have had no problems with it so far (maybe five or ten programs).

Actually, I erased all the DLL's and recompiiled with 7.04 and it still did not work.

Does not compile? Output not as expected? If iyou've been using since PB/1 you should know that "does not work" is not really much to go on.

Perhaps I had some "cross contamination" since I have both 7.04 and 9.00 installed on the same machine

Compiler does not link anything external, so that is not the problem.

Log file shows full path of all #INCLUDE'd files. Check it.

This will tell you from where your DLLs are loading:
Show Loaded Modules Source and Executable package for PB and VB
Visual Basic include files/demo code by Balthasar Indermuehle. (PB code by YT.)

One thing I noticed is that none of my custom control would work when I used the Control Add statement

Does not compile? Control not created? Control created but does not perform as expected? Break the rules re mixing/matching "DDT" with "SDK" code? (Some of these rules you could break with impunity with earlier versions, but just like the Windows API, as new versions come along the editing gets tighter and the restrictions start actually restricting).

the existing code worked fine in 7.04.

You sure about that? Maybe you had errors which were masked by something in those versions.

First thing you do, recompile all with #DEBUG ERROR OFF... force a GPF when you 'make a no-no.'

No GPF? Well, bad news, you'll have to find your problems the old-fashioned way. Fortunately the #TOOLS added in 7x make this a whole lot easier than it was in PB/1 thru PB/6.

Are there bugs in 9x? Yes. Have they all been posted in the PowerBase Forum yet? No. Is it PB's intention to post them? So I have been told.

However, absent your code there is no way anyone can tell which - if any - of these bugs may be affecting your program(s).

MCM

[Jeff Radue]

Your right Michael, every version of PBWin seems to get a little tighter on how you use the code. I have mixed SDK and DDT routinely without much trouble. In many cases the DDT is much quicker and less coding, so I use it. The issue with the custom controls is that they simply will not be created using Control Add. The program itself appears to run fine and everything compiles. At this point I am recoding using the SDK. Not a really big deal, since I am an SDK purist as heart anyway.

At this point I will assume it is just lazy coding practice that has caused the problems.

[Michael Mattias]

Just a few observations...

InitGraphWinCtrl hInst&
  CONTROL ADD "TGGRAPH", hWnd, CtrlId, "", vLeft, vTop, vWidth, vHeight, _
  %WS_VISIBLE OR %WS_CHILD OR %DS_CONTROL, %WS_EX_CLIENTEDGE
  CONTROL HANDLE hWnd, CtrlId TO hwin

=========

hwin      = CreateWindowEx(flag&,"TGGRAPH","",%WS_VISIBLE OR %WS_CHILD OR % DS_CONTROL, _
vLeft,vTop,vWidth, vHeight, hWnd, [B][COLOR="Red"]byval %NULL[/COLOR][/B],_
 hInst&,BYVAL %NULL)                
  d         = SetWindowLong(hwin,%GWL_ID,CtrlId)

Well, that's certainly a start; it's also a little "different"

I assume "Flag&" = %WS_EX_CLIENTEDGE in CreateWIndowEx

I don't understand why you are not simply setting the control ID in CreateWindowEx using the "RED" parameter.

It goes without saying I assume hWnd, hInst&, vLeft, vTop, vWidth, vHeight and CtrlId have been set to legal values.

Curious you are not checking in the DDT example for the alleged success of InitGraphWinCtrl, as failure here would absolutely 100% explain why the control is not created. (In the CreateWindowEx example, you get a value but do not test it).

Just for kicks, in the DDT example for the style to be evaluated by putting parens around it...

CONTROL ADD "TGGRAPH", hWnd, CtrlId, "", vLeft, vTop, vWidth, vHeight, _
  (%WS_VISIBLE OR %WS_CHILD OR %DS_CONTROL), %WS_EX_CLIENTEDGE

.. or make it variable or equate....

CtrlStyle = %WS_VISIBLE OR %WS_CHILD OR %DS_CONTROL
  CONTROL ADD "TGGRAPH", hWnd, CtrlId, "", vLeft, vTop, vWidth, vHeight, _
  CtrlStyle, %WS_EX_CLIENTEDGE

.. and see what happens. (This control is a dialog box of some kind? DS_CONTROL style is a little unusual for a "CONTROL").

[Jeff Radue]

I assume "Flag&" = %WS_EX_CLIENTEDGE in CreateWIndowEx

Yes, you are correct. I changed that parameter to a variable so I can omit the border in some situations.

I don't understand why you are not simply setting the control ID in CreateWindowEx using the "RED" parameter.

Good suggestion. I should have read the description for that parameter more carefully. I assumed it was only for menu handles.

 
CONTROL ADD "TGGRAPH", hWnd, CtrlId, "", vLeft, vTop, vWidth, vHeight, _
  (%WS_VISIBLE OR %WS_CHILD OR %DS_CONTROL), %WS_EX_CLIENTEDGE

This did not work. However, I am only testing if the window handle is valid using a separate Control Handle statement. Is there a way to check if Control Add actually did something?

[Jeff Radue]

For giggles, here is the class definition. This does return a valid value.

 
FUNCTION InitGraphWinCtrl(BYVAL hinst&) AS LONG
LOCAL wc AS WNDCLASSEX
local szClassName AS ASCIIZ * 80
 
szClassName = "TGGRAPH"
wc.cbsize = SIZEOF(wc)
wc.style = %CS_DBLCLKS 'OR %CS_HREDRAW OR %CS_VREDRAW
wc.lpfnWndProc = CODEPTR(GraphPrevProc)
wc.cbWndExtra = %TGWINEXTRA
wc.hInstance = hinst&
wc.hCursor = LoadCursor(hinst&,BYVAL 304)
wc.hbrBackground = %NULL ' %COLOR_WINDOW + 1
wc.lpszClassName = VARPTR(szClassName)
FUNCTION = RegisterClassEX(wc)
END FUNCTION

[Michael Mattias]

You might check what you are returning from the WndProc for that control in response to WM_CREATE, WM_NCCREATE and/or any other notification messages you pick up.

IIRC the handling of that changed in 8x DDT.