PureBasic 6.10 LTS is out !

[jacdelad]

Ah thanks. Good news.

[Axolotl]

Question about -> Added: Parent window support to all requesters

What are the benefits of this extension?
-> make a specific window the parent instead of the window with the input focus.

Because I thought that the extension would center the requester on the parent window and not always display it in the middle of the screen.

If it is being worked on now anyway, perhaps an additional flag #PB_MessageRequester_WindowCentered similar to #PB_Window_WindowCentered could be added?

Anyway, some topics related to MessageRequester (mostly the positioning)
Re: [Implemented] Improve the input requester
MessageRequester Bug (maybe another reason)
Path Requester a simple way to control X Y?
Set Requester Position ...
Additional flag for MessageRequester to center requester on app window

[AZJIO]

What are the benefits of this extension?

I previously used AutoIt3 and the parent window descriptor parameter was always there. It was unusual for me when the message is a separate equivalent window. I am used to the message blocking access to the parent window until it is closed. If you do not need a lock, then do not specify the parent window.
Closing the parent window should close the child windows.

[Axolotl]

I am very sure that requester windows have always blocked the other application windows.
I don't want to speculate any further, so I guess I'll have to wait for the help doc.
And, to reiterate, the positioning of requesters was the most frequently mentioned request (according to my research.)

[AZJIO]

If I created a window with the program settings, it should be a child in relation to the parent. Next, if a message appears, then in relation to which window will it be a child, if my 2 windows are the same in status?

[Fred]

If you don't use the new parentid parameter it automatically look for the active window and use this as parent. Sometimes it didn't used the expected window, so now you can specify it.

[zikitrake]

I tested the code with WebViewGadget from the first post in Win 7, Win 8 and Win 10, and the window is always empty (gadget is not initialized).
Does anyone have this code working fine?

WebGadget when using a flag #PB_Web_Edge it is also not initialized.
Is this a bug?

For me WebViewGadget is working ok but Webgadget with flag #PB_Web_Edge displays a blank window



Windows 11 64, PB 6.10 Beta 64 with last Webview2 runtime installed

[Kiffi]

@zikitrake:

If you do not set the URL directly but with SetGadgetText(), then it works

Code: Select all

    WebGadget(0, 10, 10, 580, 280, "", #PB_Web_Edge)
    SetGadgetText(0, "https://www.purebasic.com")

[pamen]

it does not, when the URL is a local file file://C:\whatnot\whatever/html (no matter \ or / or URL encoded).

[zikitrake]

@zikitrake:

If you do not set the URL directly but with SetGadgetText(), then it works

Code: Select all

    WebGadget(0, 10, 10, 580, 280, "", #PB_Web_Edge)
    SetGadgetText(0, "https://www.purebasic.com")

Thank you!

[Kiffi]

@pamen: The same as zikitrake:

Code: Select all

  WebGadget(0, 0, 0, 800, 800, "", #PB_Web_Edge)
  SetGadgetText(0, "file://c:/temp/helloworld/index.html")

[pamen]

@Kiffi
sorry, I'm getting this only in a single form simple example, in a complex form scenario (some forms hidden, no web gadget, some visible, web gadgets) I get no gadget, just the container, no matter if I put "" on creation or not.
I will check again in a month, I'm sure I cannot be the only one having issue with instantiating WebGadget with Chrome.

[akee]

Saw this... PackEntryDate()... PureBasic developers rock...

Thanks Fred...

[ChrisR]

@Fred:
Something is off / different with the handling of pointers as return values of a function.

I also noted that pointers defined as long variables used to work, but this is no longer the case now for Windows x64 compilations.
At default of a *pointer variable, an Integer is now required.

Code: Select all

lpbData.l = AllocateMemory(256)
FreeMemory(lpbData) <== Crash

rulptr.l = @RulesList() <== Wrong pointer

I had to fix a few old programs, and they work as expected now, with 6.10 beta1.
But I've also noted some code here and there on the forum that uses long variables for pointers, unfortunately, they won't work anymore if compiled in 64-bits, with version 6.10 now.

[Fred]

Using .l for pointer in x64 is programming mistake, i'm even suprised it worked for you before.