I have a FF project that would compile and run in Windows-7 but would not run in Windows-XP (the GUI would not load- no error messages). I tried many things to resolve the problem but nothing worked. Then it was suggested that I add a statement at the beginning of each Function on the form to prevent code in that function being run until after the Form Finishes the Form_WM_Create process.
So I set a global variable (FormCreated) to %TRUE at the end of the FORM_WM-CREATE function. AND, placed a statement at the top of each Function on that Form that would check to see if FormCreated was %TRUE and if not would exit the function.
All the functions onthe form were check this way. That was the only change made to the program.
Now, the program compiles and runs correctly in both XP and Win-7.
Why would this change make a difference?
Maybe put a MSGBOX right at the beginning to identify which Functions are being called before FORM_WM_CREATE finishes. You will need to then remove the FormCreated boolean for each Function that beng called to let it run and see whether any problem there.
Probably going to be a step by step process testing for one Function at a time.
Else is there a Debug.Print sort of thing?
Using a global variable, the first form that set it to true would prevent every other form that checked the variable from executing their WM_Create code. This might be why the change makes it look like it is working but isn't. Without seeing your code, maybe it is just your explanation isn't complete.
I've run into this issue before and what I did to solve it was to use POSTMESSAGE. This is a cleaner way to perform what your suggesting. POSTMESSAGE is similar to SendMessage. The different is SendMessage is processed and does not return until complete. It is like calling a function and waiting until the function returns. On the other hand, POSTMESSAGE adds the message to the message queue and returns immediately. This allows the current function (WM_CREATE in this case) to finish before the next message in the message queue is processed. This is what you want and you don't need variable and code to keep track of it. At least this has worked for me.
The process is as follows.
. Create a custom event equate %WM_FORM_CREATE. The same custom event equate can be used for all forms.
%WM_FORM_CREATE = %WM_USER + 1000 ' Use a unique msg value above %WM_USER
. In WM_CREATE Copy the code to WM_CUSTOM and replace the call with POSTMESSAGE
WM_CREATE
PostMessage hWndForm, %WM_FORM_CREATE, 0, 0
WM_CUSTOM
Select Case wId
Case %WM_FORM_CREATE
' Put original copied code from WM_Create code here (or call a function that performs the function)
End Select
Marty,
I have never seen that before. And none of the fixes really tell you the answer to your question. As I read it, your question was "Why this behavior with XP but not Win 7?". Not enough clues to tell yet.
Could you post your form_wm_create routine? I suspect it's something in there causing your problem. I think Cho Sing Kum is on the right track. But the use of msgbox for trouble shooting things like this is usually problematic. I would enable ztrace support for that project, and sprinkle calls in your form_wm_create routine as such:Function FORM1_WM_CREATE ( _
hWndForm As Dword, _ ' handle of Form
ByVal UserData As Long _ 'optional user defined Long value
) As Long
ztrace "WM_CREATE Start"
ztrace "Calling GetLocalDrives"
GetLocalDrives ' Populate the Local drive Checkbox-List
ztrace "Setting up the Prgress bar"
'Set up the progress bar
Local nTop,nLeft,nWidth,nHeight As Long
FF_Control_GetLoc (HWND_FORM1_LPROGRESSBARBACKDROP, ByRef nLeft, ByRef nTop)
FF_Control_GetSize (HWND_FORM1_LPROGRESSBARBACKDROP, ByRef nWidth, ByRef nHeight)
ghProgressBar = CreatePGBar3D (HWND_FORM1, 1080, "", nLeft+2, nTop+2, nWidth-4, nHeight-4, %WS_CHILD Or %WS_VISIBLE, 0, 0 ) 'BAR1
SendMessage ghProgressbar, %PGB_SETMAX, 100, 0 'max number of steps
SendMessage ghProgressbar, %PGB_SETBARCOL, %PGB_RED, 0 'bar color scheme
SendMessage ghProgressbar, %PGB_BUILDBARS, 0, 0 'finally, build the bars - IMPORTANT!
SendMessage ghProgressbar, %PGB_SETTXTON, 0, 2 'show own text
SendMessage ghProgressbar, %PGB_SETTXTCOLBKG, RGB(255,255,0), 0 'backgound text color
SendMessage ghProgressbar, %PGB_SETTXTCOLBAR, RGB(0,0,0), 0 'bar text color
' SendMessage ghProgressbar, %PGB_SETVALUE,50,1
ztrace "WM_CREATE End"
End Function
ztrace.dll needs to be in the same folder as your app or, as in my case, somewhere in the PATH on your machine.
If the output on the ztrace window is: WM_CREATE Start
Calling GetLocalDrives
Then you know that the last routine is not returning. If any of your routines keep the FORM1_WM_CREATE from finishing, you will never get a window for FORM1.
David
Cho, Brian and David... Thanks for the suggestions.
Because the project is quite large and contains DLL's that are licensed and require license keys I will not be able to post it. I am just glad I found a method that fixes the problem. But it would be nice to know the source of the problem.
When I get some extra time, I will try the zTrace idea.
The problem is in the startup form, I don't understand why any of the code of the controls on the startup form should fire during the FORM1_WM_Create finishes. This is the WN_CREATE function:
Function FORM1_WM_CREATE ( _
hWndForm As Dword, _ ' handle of Form
ByVal UserData As Long _ 'optional user defined Long value
) As Long
Local sTxt As String
Local sFld As String
SendMessage HWND_SuperMsgBox_RICHEDIT1, %EM_SETTARGETDEVICE, 0, 0 'Set the RTF control to have word wrap on
sTxt = "Select Customer first then enter message " & $CrLf & _
"then click on Send button. If you want to " & $CrLf & _
"send message to all clients, check the Public " & $CrLf & _
"check box. "
FF_TextBox_SetText (HWND_FORM1_RichEdit1, sTxt)
'load initial record
' sTxt = "A" : sFld = "Company"
' ClearMask (0)
' RecSearch sTxt, sFld, 3, ">="
FF_Control_SetFocus(HWND_FORM1_Text1)
frmCreateDone = 1
End Function
[code]
Should I relocate some of this code to a different function. If so, where?
Well, I thought I got it fix. At least the gui loads. But now I get and "Application Error" message. It says:
"The instruction at "0x004344a6" referenced memory at "0x00a83000". The memory could not be "written".
I assume this is a Windows message. Funny thiing is the program runs fine in Windows7 but now crashes in Windows-XP. This happens during a function that executes an SQLite/SQLitening routine.
Being new to FF/PB, so far, I have only been playing with getting the GUI working correctly. I have not started rewriting my VB6 programs in FF/PB yet so there are a lot of things I do not yet know how to implement in FF/PB.
With regards to error trapping, I am just reading up the PB help and there are indications that I can do the same as what I do in VB6. I have error trapping in ALL Subroutines and Functions. The following is actual VB6 codes of a Subrountine that shows the error trapping.
Line 100 turns on error trapping in this Sub.
Line 540 to 560 are the error trapping codes that:
a) display the error number
b) display the error description
c) the line number in this Sub that the error occur
d) the name of the code module (in this case frmBonus.Form_Load)
This way, I can always get to where errors are thrown.
Private Sub Form_Load()
100 On Error GoTo ErrorHandler
101 Dim i As Integer
102 Dim strItemText As String
110 Dim Reader As New MLReader
120 Dim Periodicity As String
220 Call SendMessage(ListViewSymbolList.hWnd, LVM_SETTEXTBKCOLOR, 0&, ByVal CLR_NONE)
230 Call SendMessage(ListViewSymbolList.hWnd, LVM_SETBKIMAGE, 0&, BKIMG)
240 Call SendMessage(ListViewSymbolList.hWnd, LVM_SETEXTENDEDLISTVIEWSTYLE, LVS_EX_FULLROWSELECT, ByVal True)
250 Call SendMessage(ListViewSymbolList.hWnd, LVM_SETEXTENDEDLISTVIEWSTYLE, LVS_EX_GRIDLINES, ByVal ShowGrid)
260 DTPickerExDate.CustomFormat = "dd-MMM-yyyy"
270 DTPickerExDate.Value = Now
280 ListViewSymbolList.ListItems.Clear
290 ListViewSymbolList.ForeColor = QBColor(NormalFontColor)
291 For i = 1 To 100 Step 1
292 strItemText = CStr(i)
293 SendMessage cboBonusShare.hWnd, CB_ADDSTRING, 0, ByVal strItemText
294 Next i
295 For i = 1 To 100 Step 1
296 strItemText = CStr(i)
297 SendMessage cboShareHeld.hWnd, CB_ADDSTRING, 0, ByVal strItemText
298 Next i
300 If Reader.IsMetastockDirectory(StocksDataPath) = False Then Exit Sub
310 Reader.OpenDirectory StocksDataPath
320 Do While (Reader.iMaRecordsLeft > 0)
330 Reader.ReadMaster
340 Select Case Reader.MaPeriodicity
Case "0"
350 Periodicity = "Intraday"
360 Case "1"
370 Periodicity = "Daily"
380 Case "2"
390 Periodicity = "Weekly"
400 Case "3"
410 Periodicity = "Monthly"
420 End Select
430 With ListViewSymbolList.ListItems.Add(, , Reader.sMaSecName)
440 .SubItems(1) = Reader.sMaSecSymbol
450 .SubItems(2) = Periodicity
460 .SubItems(3) = Reader.iMaFirstDate
470 .SubItems(4) = Reader.iMaLastDate
480 End With
490 Loop
500 Reader.CloseDirectory
510 cboBonusShare.ListIndex = 0
520 cboShareHeld.ListIndex = 0
Terminate:
530 Exit Sub
ErrorHandler:
540 ErrMsg = "Number: " & Err.number & vbCrLf & _
"Description: " & Err.Description & vbCrLf & _
"Location: at line " & Erl & vbCrLf & _
"Module: in frmBonus.Form_Load"
550 MsgBox ErrMsg
560 Resume Terminate
End Sub
Quote from: Marty Francom on December 31, 2009, 02:44:57 PM
Well, I thought I got it fix. At least the gui loads. But now I get and "Application Error" message. It says:
"The instruction at "0x004344a6" referenced memory at "0x00a83000". The memory could not be "written".
I assume this is a Windows message. Funny thiing is the program runs fine in Windows7 but now crashes in Windows-XP. This happens during a function that executes an SQLite/SQLitening routine.
Been there too.
In Special Functions FF_APP_START add:
#Debug Display On
I also bet that once you figure out what the issue is, the original problem with the UI not appearing will go away if you change the code back to what you had before.
There must be a difference in the way WinXP and Win7 handle memory. I can't say for sure, but it sounds like WinXP is crashing due to trying to access memory outside it's process (in other words it is executing and crashing because it gets something it doesn't expect). Where in Win7, Microsoft probably added some protection, hey wait that memory isn't in your process, you don't get to go there, stops the application from accessing that memory. Just a guess, but sounds like a good one.
Post back when you figure out what it is. It will help all of us from making the same mistake.
If you can't find it and can reduce the problem to an example, maybe I and others can take a look at it to help you figure it out. I know you don't want to post your project. If you'd like some help off line I'd be happy to take a look.
I just keep getting more puzzelled. I thought maybe "Theme Support" might be causing a problem for Win-XP. So, I turned off "Theme Support" in FF project properties. Now, a the program crashes in Win-7 after a short time. Turn "Theme Support" back on and re-compile and it works properly in Win-7 again.
Why would this be so? I think I must have fallen down the rabbit hole, Alice must be around here somewhere. It must be tea time.
What is the first control in tab order in FF IDE? Usually it is set focus to and I notice in your WM_CREATE you also set focus. Could there be a conflict and/or a focus change causing something else to execute you don't expect?
Hi Marty,
I just installed the WinXP Mode virtual PC files in my Windows 7. I ran a version of the files that you sent to me before Christmas. As you have said, it does fail in WinXP but seems to run okay in Windows 7.
I will poke around a bit tonight to see if I can track down where your program is failing.
The error occurs in your "BuildGrid" function when it is called from your "RecSearch" routine. I have not yet traced the exact position of the error but it occurs during the code marked with the comment "Step 2 - Find next 3 records".
I'll report back again once I get deeper into the problem.
From what I can tell, the GPF occurs as you are building the string to display in the "grid". It appears that it may be related to building the string and using a negative number in the SPACE$() function. Whatever the case, I will re-write your BuildGrid function to eliminate any chance of the GPF. Once finished, I will email it to you privately.
I just want everyone here to realize that this is not an FF3 problem.
Hi Marty,
I have emailed you a new "BuildGrid" function using more consie and efficient code (uses PB's LSET$ function rather than PARSE$, SPACE$, LEN, etc).
The new code works for me and does not GPF in WinXP or Windows 7.
Please let me know if it works okay for you.
Yes, Paul this works for me in both Win-7 and Win-XP.
I admit I am at best a hobbyist programmer. I would like to learn how to better find such errors. Can you explain how you were able to find the error?
Also, one other problem that is still occurring. If you turn OFF "Theme Support" in the project properties. The program will crash when run in Win-7. Any idea why this is occurring?
Is it fair to say that "Programs developed in Win-7 should be well tested in Win-XP because Win-7 can hide this type of problem and it will only show up if the program gets run in Win-XP."
Hi Marty,
I found your problem by a simple process of elimination. I figured there must be code in the WM_CREATE that was causing the program to fail to load, otherwise we would at least see the GUI flash on to the screen and then vanish.
I commented out the calls to "ClearMask" and "RecSearch" and the program appeared. I then uncommented the "ClearMask" and it ran okay, however once I uncommented the "RecSearch" then the fail happened again.... so, I started to dig into the "RecSearch".
What I normally do when digging into a problem like this is that I will place either MsgBox's or "?" calls at various points in the function. I number them consecutively so I can watch them appear on the screen. Things like, ? "1", ?"2", ?"3", etc... I take note of the last number that appears on screen so I know that the bad code occurs between that number and the next one in sequence. I continue the process until I narrow it to the point of where the fail happens. This process works well most of the time. It will fail of course if you are trying to debug a SetFocus problem or similar because the MsgBox's will screw up the focus.
I guess that I could have tried running the whole program through PB's Debugger.... but I didn't. Haven't used that tool in a long while.
Not sure about the Theme Support thing you're talking about.... I haven't done any investigation into that. If I get some time this afternoon then I'll try to tackle that. :)
Quote
Not sure about the Theme Support thing you're talking about.... I haven't done any investigation into that. If I get some time this afternoon then I'll try to tackle that.
Something has changed between the code you sent me before Christmas and the code you sent to me today. The code before Christmas will compile and run fine with both Themes On or Off. The new code GPF's about half way through showing the main Form.
I'll see if I can find an answer.
Marty - I sent you a modified version of your masked edit functions. They were causing recursion in your code that eventually caused the GUI to crash. For some reason with Themes turned on, this recursion did not crash Win7. Windows can be so weird.
Paul,
Thanks greatly for your help. Maybe with Themes set ON, that created enough of a delay that these functions were able to finish before the recursion could occur???
I will add the change you suggested to the MaskEdit Sample program that I posted so that others don't run into this problem, if they should be using that MaskEdit code in their programs.