All Activity

Олимп Казино — это одно изо самых фаворитных казино в течение России, предлагающее разнообразные зрелище а также развлечения чтобы любителей целеустремленных игр. С в минуту свой в доску основания оно захватило репутацию верного заведения, приковывающего яко начинающих, так а также опытнейших игроков. Игровое Предложение В ТЕЧЕНИЕ Олимп Толпа доступен широкий выбор игровых автоматов, настольных игр и еще жизненного казино. Игроки могут благодушествовать традиционными выступлениями, таковскими яко хорс и фортунка, что-что также новыми слотами, коие регулярно обновляются https://spikefst.com/col/#comment-323226 Бонусы а также Промо-акции https://www.prowi-studie.de/viel-hilft-viel-exzessives-arbeiten-und-erschoepfung/?unapproved=399949&moderation-hash=c9eefed46389cb1aa6d59c54363e8d40#comment-399949 Толпа предлагает тороватые http://forum.exalto-emirates.com/viewtopic.php?f=7&t=130614&p=1494986#p1494986 скидки равным образом буферный) запас чтобы свой в доску клиентов. Новички смогут рассчитывать на приветственный тантьема, который усиливает ихний перевес на выигрыш. Регулярные игроки также могут наслаждаться программами преданности также особенными предложениями. Безопасность а также Суперлицензия Лахо Толпа блюдет все нужные http://www.liliy.cn/?page_id=17&cpage=1&unapproved=210865&moderation-hash=4d5b419a5884d7599352dfcd7c62efd8#comment-210865 штампы защищенности а также иметь в своем распоряжении разрешение, обеспечивающуюFair Play. Это ручается игрокам предохрану личной инфы а также чистота игр.

Hello & Welcome to the µGFX community! This can be done by defining a custom keyboard layout and setting it via gwinKeyboardGetEventSource(). You can have a look at the built-in layout as a reference which you can find under src/gwin/gwin_keyboard_layout.c

I would like to know if there is such an option to change the on-screen keyboard layout language? I would like to change it to my own language. If so, do I need to change the library files? Could you please tell me how to do it?

Glad to hear that!

Yes, thank you (and of course M3Michi) very much! I ported M3Michi's code to STM32F4 and now everything works much faster!

Hi! Have you tried just running the unmodified example found under /demos/modules/gwin/button ? With regards to calibration: You would typically only ever do that once (or if you build a full application, have some "settings" menu where the user can re-launch the calibration sequence). Once calibration was performed, you'd typically store the calibration data and load it on power-on. Have you had a look at the corresponding documentation? https://wiki.ugfx.io/index.php/Touchscreen_Calibration

Hello & Welcome to the µGFX community! Have you checked out the attached archive in @M3Michi 's last post?

Hello! Sorry for using an old thread, but I'm running into the same performance issue as M3Michi. I would like to use SPI DMA in my project with STM32F4 and ili9341. I can imagine the architecture of the solution, but having an example of implementation from M3Michi I would do it much faster. Could you please update the link to M3Michi's project or publish his implementation of the "gdisp_lld_ILI9341" driver? I sure this example would be very useful for everyone who want to use combination of DMA and ili9341 in STM32. Thanks for your uGFX!

Ищете труднодоступные товары или услуги? Mega предлагает самые редкие и непростые для нахождения позиции. Регистрация на платформе мега ссылка занимает всего несколько минут, а пополнение баланса вашего аккаунта происходит буквально за считанные секунды. ссылки на мега дарк предлагает тысячи редких товаров и услуг, с возможностью анонимной оплаты, уже ожидающих вас на своих страницах торговой площадки. mega at: https://xn--megsb-l11b.com

Всем привет Наша компания проводит акцию по бесплатной приемке квартир у застройщика ООО СЗ "Пик-Тура" в Москве и Московской области, приемка для вас будет абсалютно бесплатна при заключении договора на взыскание компенсации за строительные недостатки, за который вы оплачиваете только гонорар успеха и возмещение судебных расходов. Порядок приемки квартиры по законодательству России Принятие квартиры является важным этапом в процессе приобретения жилья. Согласно статье 4 Федерального закона № 214-ФЗ « Об участии в долевом строительстве…» основными обязанностями участника долевого строительства является оплата установленной договором цены и принятие объекта долевого строительства. В данной статье мы обозначим точный порядок действий участника долевого строительства при приемке квартиры с учетом действующих норм закона. 1. Получение сообщения от застройщика о готовности объекта недвижимости к передаче и необходимости принятия объекта долевого строительства. https://priemka-kvartiry-pik.ru/ приемка квартиры документы от застройщика [url=https://priemka-kvartiry-pik.ru/]помощь в приемке квартиры приемка квартиры приемка квартиры в новостройке приемка квартиры в новостройке с отделкой приемка квартиры москва Как правильно принять квартиру от застройщика? чек лист для приемки квартиры от застройщика заказать приемщика квартиры отзыв приемщику квартиры приемку квартиры от застройщика приемщик квартиры в новостройке цена приемка квартир от застройщика в москве приемка квартир под отделку приемка квартиры с отделкой советы компания по приемке квартиры у застройщика претензии при приемке квартиры от застройщика чек лист приемки квартиры от застройщика приемка квартиры без отделки чек лист приемка квартиры с отделкой что проверять критерии приемки квартиры в новостройке от застройщика пик приемка квартиры специалист доверенность на приемку квартиры у застройщика по дду как осуществить приемку квартиры от застройщика приемка квартиры в новостройке с черновой отделкой найти приемщика квартир домклик приемка квартиры в новостройке от застройщика приемка квартиры от застройщика фирмы приемка квартиры документы от застройщика этапы приемки квартиры у застройщика приемка квартиры от застройщика специалист самостоятельная приемка квартиры без отделки правила приемки квартир с отделкой приемка квартиры застройщика новостройке порядок приемки квартиры в новостройке у застройщика чек лист приемка квартиры в новостройке с отделкой услуги приемщика квартиры приемка квартиры у застройщика услуга приемка квартиры от застройщика стоимость инженер приемщик квартир нужна ли приемка квартиры без отделки стоимость приемки квартиры в новостройке с отделкой услуги приемщика квартиры в новостройке приемка квартиры у застройщика снип приемка квартиры от застройщика самостоятельно [/url] [url=https://priemka-kvartiry-pik.ru/]Эксперт по приемке ПИК[/url] variant3

Good day to all!! I am continuing my study of uGFX very slowly. Next stuff - widgets... To understand the work, I took an example from \ugfx_2.9\demos\modules\gwin\button. I added the missing, in my opinion, function calls: ginputCalibrateMouse(), geventAttachSource(); Now the code looks like this: #include "gfx.h" #include <stdio.h> #include <string.h> #include <stm32f10x.h> #include "uGFX/gdriver/gdriver.h" #include "uGFX/ginput/ginput_driver_mouse.h" static GListener gl; static GHandle ghButton1; static void createWidgets(void) { GWidgetInit wi; // Apply some default values for GWIN gwinWidgetClearInit(&wi); wi.g.show = TRUE; // Apply the button parameters wi.g.width = 100; wi.g.height = 30; wi.g.y = 100; wi.g.x = 100; wi.text = "Push Button"; // Create the actual button ghButton1 = gwinButtonCreate(NULL, &wi); } int main(void) { GEvent* pe; GMouse * m; GSourceHandle gs; // =========== Timer setup block ================== SystemCoreClockUpdate(); SysTick_Config(SystemCoreClock /1000); //================================================= // Initialize the display gfxInit(); m = (GMouse *)gdriverGetInstance(GDRIVER_TYPE_MOUSE, 0); // === Added by me ====== ginputCalibrateMouse(0); // ====================== gs = ginputGetMouse(0); // Set the widget defaults gwinSetDefaultFont(gdispOpenFont("UI2")); gwinSetDefaultStyle(&WhiteWidgetStyle, FALSE); gdispClear(White); // create the widget createWidgets(); // We want to listen for widget events geventListenerInit(&gl); // === Added by me ====== geventAttachSource(&gl, gs, GLISTEN_MOUSEMETA | GLISTEN_TOUCHMETA); // ====================== gwinAttachListener(&gl); while(1) { // Get an Event pe = geventEventWait(&gl, TIME_INFINITE); switch(pe->type) { case GEVENT_GWIN_BUTTON: if (((GEventGWinButton*)pe)->gwin == ghButton1) { // Our button has been pressed printf("Button clicked\r\n"); } break; default: break; } } return 0; } There is no response to touching the button. What am I doing wrong? ginputCalibrateMouse() is executed, the driver ADS7843 works correctly...

Hello, I am experiencing an anomaly involving containers and I wanted to understand if it is an intentional thing or it happens due to my settings/programming. I have a menu cotainer declared as follow: void createWidgetsMenuTST(GDisplay* _display1) { GWidgetInit wi; gwinWidgetClearInit(&wi); wi.g.show = FALSE; wi.g.width = 800; wi.g.height = 480; wi.g.y = 0; wi.g.x = 0; wi.customStyle = &MyCustomStyleContainerTST; ghContainerTST = gwinGContainerCreate(_display1 , 0,&wi,0); I have a second container that contains buttons, like it was a keyboard and I want to make the keyboard and all the buttons in it disappear/appear. To do this I use the gwinHide and gwinShow methods void createWidgetsKeyboard(GDisplay* _displayToUse) { GWidgetInit wi; gwinWidgetClearInit(&wi); wi.g.show = FALSE; wi.g.width = 799; wi.g.height = 279; wi.g.y = 200; wi.g.x = 0; wi.g.parent = ghContainerTST; wi.customStyle = 0; wi.customDraw = ContainerCustomDrawKeyboard; ghContainerNumericKeyboard = gwinGContainerCreate(_displayToUse , 0,&wi,0); gwinWidgetClearInit(&wi); wi.g.show = TRUE; wi.g.width = 124; wi.g.height = 124; wi.g.y = 11; wi.g.x = 15; wi.text = "1"; wi.g.parent = ghContainerNumericKeyboard; wi.customParam = 1; wi.customDraw = gwinButtonKeyboardDraw_Rounded; ghButtonKey[0] = gwinButtonCreate(NULL, &wi); gwinWidgetClearInit(&wi); What happens to me is that when I call the gwinHide functions and specify ghContainerNumericKeyboard as parameter i get that also the main container (ghContainerTST) is alswo redraw. I think the problem is in function void WM_Redraw(GHandle gh) inside "gwin_wm.c" In particular i think that the redraw is done by gdispGFillArea function called on the "else" statement. I don't quite understand if it is avoidable this thing of redrawing containers of containers for example by editing the configuration file or if there are other ways to avoid it static void WM_Redraw(GHandle gh) { gU32 flags; flags = gh->flags; gh->flags &= ~(GWIN_FLG_NEEDREDRAW|GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); #if GWIN_NEED_CONTAINERS redo_redraw: #endif if ((flags & GWIN_FLG_SYSVISIBLE)) { if (gh->vmt->Redraw) gh->vmt->Redraw(gh); else if ((flags & GWIN_FLG_BGREDRAW)) { // We can't redraw but we want full coverage so just clear the area gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gh->bgcolor); // Only do an after clear if this is not a parent reveal if (!(flags & GWIN_FLG_PARENTREVEAL) && gh->vmt->AfterClear) gh->vmt->AfterClear(gh); } #if GWIN_NEED_CONTAINERS // If this is container but not a parent reveal, mark any visible children for redraw // We redraw our children here as we have overwritten them in redrawing the parent // as GDISP/GWIN doesn't support complex clipping regions. if ((flags & (GWIN_FLG_CONTAINER|GWIN_FLG_PARENTREVEAL)) == GWIN_FLG_CONTAINER) { // Container redraw is done for(gh = gwinGetFirstChild(gh); gh; gh = gwinGetSibling(gh)) _gwinUpdate(gh); return; } #endif } else { if ((flags & GWIN_FLG_BGREDRAW)) { GHandle gx; #if GWIN_NEED_CONTAINERS if (gh->parent) { // Child redraw is done // Get the parent to redraw the area gh = gh->parent; // The parent is already marked for redraw - don't do it now. if ((gh->flags & GWIN_FLG_NEEDREDRAW)) return; // Use the existing clipping region and redraw now gh->flags |= (GWIN_FLG_BGREDRAW|GWIN_FLG_PARENTREVEAL); goto redo_redraw; } #endif // Clear the area to the background color gdispGFillArea(gh->display, gh->x, gh->y, gh->width, gh->height, gwinGetDefaultBgColor()); // Now loop over all windows looking for overlaps. Redraw them if they overlap the newly exposed area. for(gx = gwinGetNextWindow(0); gx; gx = gwinGetNextWindow(gx)) { if ((gx->flags & GWIN_FLG_SYSVISIBLE) && gx->display == gh->display && gx->x < gh->x+gh->width && gx->y < gh->y+gh->height && gx->x+gx->width >= gh->x && gx->y+gx->height >= gh->y) { if (gx->vmt->Redraw) gx->vmt->Redraw(gx); else // We can't redraw this window but we want full coverage so just clear the area gdispGFillArea(gx->display, gx->x, gx->y, gx->width, gx->height, gx->bgcolor); } } } } }

Definitely on the ToDo list to check this out. Have to get the v2.10 release out first tho (pretty much done at this point).

Thank-you.

Updated patch! (I found and fixed a cornercase glitch when kerning right-justified text) FlickerlessFillstring_2.patch

Firstly: It was impossible for the font rendering to use the public functions gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop(), because of the mutex. So the patch make these three functions private with new names: StreamStart(), StreamColor(), StreamStop(), with public APIs gdispGStreamStart(), gdispGStreamColor(), gdispGStreamStop() handling the mutex and calling the private functions. And now to answer your question: The patch provides an option GDISP_FLICKERLESS_FILLSTRING. Turn it off, and everything is as before. Turn it on, then yes font rendering with fill will use StreamStart(), StreamColor(), StreamStop(). You may very well decide to remove the option GDISP_FLICKERLESS_FILLSTRING, and just turn the change on permanently. I just felt it was practical to have it as an option for testing purposes. Makes it easy to switch back and forth. The patch does NOT add a count parameter. That would be a driver compatibility breaking change. I just suggest that you add a count parameter in UGFX 3.0. It is an easy change with obvious advantages, given that gdisp_lld_write_color() and gdispGStreamColor() are currently called in loops in many places in UGFX.

Does that mean your patch changes font rendering (the actual painting) to use gdispGStreamStart(), gdispGStreamColor() and gdispGStreamStop()? And then on top of that giving gdispGStreamColor() an additional "count" parameter? Apologies if I'm way off here - totally buried at the moment.

There is nothing driver-specific in the patch AFAIK. Performance should be good on any driver, since it uses the generic streaming functions in gdisp which are already optimized for many types of drivers. But of course, I don't have access to every type of display driver for testing.

We had a short internal discussion about this. We'll gladly have a look at your patch but we'll need a bit more time as we're quite busy at the moment. In general, we're quite keen on this additional/improvement if it is not restrictive to a particular type of driver.

The macros using set_rd and clr_rd are macros for a reason. Those pins may be used within a gdisp hardware abstraction layer file to implement the GDISP reading functionality. If your driver or your hardware implementation does not support reading then those macros are unnecessary and, like the uftf library does, you can tie the physical pin up. With regard to the palSetPad and palClearPad, this refers to the LOGICAL level, not necessarily the physical voltage. Depending on your hardware it may be using negative or open collector logic which would give you the effect you see. Note: there are also some user contributed drivers that actually do get this the wrong way around. I am not sure without digging if the SSD1963 driver is one of those.

Not sure I see why the responsibility of bounding can't remain at the higher layer when a count argument is added?

Thank's for your reply! This solution is work perfectly!

Yes this is something that is part of uGFX v3. It is also not quite that simple for all types of displays. You might be working with a display that uses a window based driver, but there are also framebuffer drivers, and other strange types of drivers (like window drivers with positioning, dma etc). There is actually a lot of complexity in just adding that count relating to bounding. At the moment those questions are relatively simple as the calcs are done at the higher layer. When you add the count some of that bounding needs to be moved down a layer, adding to the complexity. This is why this task is in v3. It is at least a major version number update to add that stuff (along with other stuff we wanted in v3).

There are gwin calls that can resize a widget. Try starting there. I am thinking something like: 1. Change the size of the table when you display the console. 2. Change the size back when you hide the console. How you handle this will really depend on what you are doing with your console window and table widget.

#if GDISP_NEED_CLIP gdispGSetClip(gw->g.display, gw->g.x +gw->g.width -4, gw->g.y +offset +1, bar_width, bar_height); #endif