Recent Posts

Pages: 1 [2] 3 4 ... 10
Beginner questions / Re: Regular expression won't compile.
« Last post by frankie on May 26, 2020, 06:34:20 pm »
As far as I know PellesC regex are based on original Henry Spencer code, that don't supports non-greedy operators (and many other new features).
Beginner questions / Regular expression won't compile.
« Last post by gbr on May 26, 2020, 04:32:57 pm »
I'm trying to match the filename base and the extension of a Windows file path.

I'm using a using a regex that I've used before, from here :
the regex is (.+?)(\.[^.]*$|$)

Code: [Select]

char * source = "F:\\Pelles C Programs\\test\\test.exe";
char * regexString = "(.+\?)(\\.[^.]*$|$)";
regex_t regexCompiled;

  if (regcomp(&regexCompiled, regexString, REG_EXTENDED))
      printf("Could not compile regular expression.\n");
      return 1;

But regcomp returns a error.
if I print regexString, it is exactly as I mentioned above.

EDIT : Came across this :
The *? non-greedy operators is an enhanced non-POSIX feature borrowed from Perl. You get them with REG_ENHANCED.
Is that the reason ?

Beginner questions / Re: Simple way to copy string to the clipboard ?
« Last post by gbr on May 24, 2020, 12:05:06 pm »

There's no 'Like'/'Thanks' button on this forum?

I just copied the code from SetClipboardText here :

works ok.
Beginner questions / Re: Simple way to copy string to the clipboard ?
« Last post by John Z on May 24, 2020, 11:09:29 am »
Yes special functions AND you need to do some work too....
Here is a reference and some code that I used in a Pelles C project. 
This version is for Unicode so if you want just plain text you'll figure that out.
// modified from

Code: [Select]

        // string to send to the clipboard is pointed to by p_data
strsize = wcslen(p_data) * sizeof(wchar_t);
// test to see if we can open the clipboard first
if (OpenClipboard(gHWND))
// Empty the Clipboard and free the memory

// allocate a block of data equal to the text
HGLOBAL hClipboardData;
hClipboardData = GlobalAlloc(GMEM_DDESHARE, strsize + 2);

// GlobalLock returns a pointer to the
// data associated with the handle returned from
// GlobalAlloc
wchar_t *pchData;
pchData = (wchar_t *)GlobalLock(hClipboardData);

// wide strcpy function to copy the data from the local
// variable to the global memory.
wcscpy(pchData, p_data);

// unlock the memory

// Set the Clipboard data by specifying that
// unicode text is being used and pass the handle to
// handle to the global memory.
SetClipboardData(CF_UNICODETEXT, hClipboardData);

// close the Clipboard

Hope this gets you started. You still need to do some work around it of course. ;)

Beginner questions / Simple way to copy string to the clipboard ?
« Last post by gbr on May 24, 2020, 08:38:48 am »
I just started coding again, after like 25 years  :) .

I stumbled on Pelles C, and started coding in C.

I would like to copy a string to the clipboard. Is there any simple way to do that - like a user defined function or library ?
Or would I have to write it myself ?

Windows questions / Windows GDI and Dibsections
« Last post by Tom on May 24, 2020, 01:03:38 am »
Although there are many better ways to do this, from Vulkan to OpenGL to DirectX, I have always derived personal satisfaction from simple act of software rendering.  When it's just me, the instruction set, a pixel pointer and and the framebuffer, there is something direct and amusing about it. Even the lowest level APIs don't seem to capture the magic for me quite as well.

Now... Of course, with Windows, there is no way I can directly go and muck with the graphics device, so my traditional approach has been to create a window and a DIB section. I draw whatever into the section, call either SetDIBitsToDevice or BitBlt, and all is fine with the world.

However, I was wondering if anyone here is more experienced with these things, and whether there would be even better way of doing this than the current method.

Also, does anyone know what exactly happens when the DIBsection is blitted on screen?  I have deduced pretty much, that the memory latency/bandwidth is a decisive bottleneck, especially when trying anything even remotely fancy, such taking mip-mapped, trilinear samples, from multiple different textures ( raw data buffers in RAM ), resulting in tons and tons of guaranteed cache and even TLB misses the way things are.

My recent thought has been to create the DIBsections with 16 bits per pixel, effectively halving the memory footprint per fragment, and using likewise 5/5/5 : 16 bit encoded texels in memory as my texel sources.

But is there even anything to gain from this? Sure, my sampling and rasterizing may be boosted some, but what will the blitting function make of all this?  Will it just convert the dib into a 32 ARGB / 24 RGB behind my back and shuffle it over to VRAM? Will it shuffle it over as such, and convert it with the GPU in hardware? 

I have mostly been pondering about using multiple threads to pipeline the whole rendering task in two or three steps, with blitting, dib section filling and whatever else happening pretty much in parallel ( double buffering in software side ).  Of course, this whole scheme amounts to nothing, if the blitting routine ends up eating all the memory bandwidth, and all stages sit in wait-states, fighting over cache lines and waiting for their memory transactions ( which may happen regardless.... ).

Again, I know this is not a serious pursuit these days, but it's just too much fun to give up.
And if anyone has any experience/ideas how to go about this thing more efficiently, I would be grateful.   :P

Windows questions / Re: GDI+ Question
« Last post by frankie on May 23, 2020, 11:04:25 pm »
Windows questions / Re: GDI+ Question
« Last post by John Z on May 23, 2020, 08:36:28 pm »
Thanks Frankie.  Also, again thanks for all the work you did to make GDI+ easier to use under C.

Windows questions / Re: GDI+ Question
« Last post by frankie on May 23, 2020, 06:59:21 pm »
Not really clear the reason for this behavior, although you can found that a lot of people is asking the same question about the issue if you google around.
IMHO the reason is that the GDI+ library use file mapping to access the bitmap data and the image metadata. Mapping the file expose its contents as a standard memory area, but locks the file also as side effect.
If you load the image using a stream it allows you to close the file, but doing this will expose spuriously generated errors of type: "A generic error occurred in GDI+".
The only solution, and the also the only correct one, is to make an image copy from the loaded one and dispose the original image.
Windows questions / GDI+ Question
« Last post by John Z on May 23, 2020, 05:44:59 pm »
Switching a program from OLELoadPicture to GDIPlus using Frankie's excellent (Thanks very much!) fGdiPlusFlat.h under PellesC 9.
This means I'm also trying to learn GDI+ on the go.
It is all working and I am able to display the images using GdipLoadImageFromFile then creating a compatible HDC then using GdipDrawImageRectI to draw the image to an image control.

In order to speed up redrawing the screen on resize events I retain the *gpimage created from GdipLoadImageFromFile so WM_PAINT just needs to do GdipDrawImageRectI each WM_PAINT but does not need to do GdipLoadImageFromFile each time.  This works quite well.  When the image is to be changed I first use GdipDisposeImage, then start over with the next image. All works well and very similar to the OLE stream methods.

Now my question:  Why does GdipLoadImageFromFile lock the file until GdipDisposeImage is used? The image has been read into the pointer and GdipDrawImageRectI can draw the image at any time using the pointer, to a control.  GdipDisposeImage unlocks the file but also releases the data stored at the pointer created from GdipLoadImageFromFile.  Is there a method to just unlock the file after GdipLoadImageFromFile completes? Just a curiosity mainly, but it could be convenient to release the file.

Pages: 1 [2] 3 4 ... 10