Jump to content

alank2

Members
  • Content Count

    176
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by alank2


  1. If I throw 3 buttons onto a form and set button 1's click to this, it seems the ProcessMessages doesn't fully update all the buttons status.  I can run this in bcb6 which is very old, but it behaves as expected, all 3 buttons go to gray/disabled, 3s goes by, then they are become active again, then another 3s delay before the form is available for another click.

     

    In cppb10.3 however, something different happens.

     

    The first time it is run, the first pass leaves button1 in a non normal state, but not disabled.  buttons2/3 unaffected.  When it gets to the 2nd pass where it sets the buttons to true, now it updates button1 to visible, and it disables button2 (from the earlier set to false!)

    The second time it is run, the button1 goes disabled, but buttons 2/3 stay enabled, until the second pass where button1 goes enabled, but buttons 2/3 go disabled.

     

    I think ProcessMessages was supposed to process all messages, right?

     

    (and yes, the loop where I repeatedly call processmessages every 100ms, does update them more as expected, but not instantaneously)

     

    
    void __fastcall TForm1::Button1Click(TObject *Sender)
    {
      //int i1;
    
      Button1->Enabled=false;
      Button2->Enabled=false;
      Button3->Enabled=false;
      Application->ProcessMessages();
      Sleep(3000);
    
    /*  for (i1=0; i1<30; i1++)
        {
          Application->ProcessMessages();
          Sleep(3000/30);
        }*/
    
      Button1->Enabled=true;
      Button2->Enabled=true;
      Button3->Enabled=true;
      Application->ProcessMessages();
      Sleep(3000);
    }
    
    

     

     


  2. I have them set to (left, top, width, height) 45, 80, 500, 320 in the form designer.  I also have borderstyle=none, position=designed, but at runtime if I evaluate them they are 45, 80, 516, 358 so the width and height were altered by something.  I remember a thing called scale for VCL, but I don't see it present in the FMX form.  Any ideas why the width/height changed?  Can I prevent it without forcing the width/height in the form constructor (which does work)?


  3. This is a very strange issue so I thought I'd see if anyone here has experienced anything similar:

     

    I have had a release of software at multiple locations, multiple systems, and never saw the error before 6/8 at any site including the site now having the problem (it was running fine there for months).

     

    2023-06-08 02:02:16.879  ERROR: Unsupported media file myvideo.wmv (e020212)

     

    (ignore the e020212, this is my error code to locate where the error is)

     

    Then on 6/8 and after, at only one specific location, all of the computers at this location, are giving this error only when they restart their software at 2am.  It will fail with the above exception.  If you then restart it manually later on, it will load fine, only to repeat the same problem the next day.= at 2am.

     

    
      //prompt animation
      try
        {
          FScalePrompt->MediaPlayer1->FileName="c:\\programdata\\myprog\\myvideo.wmv";
        }
      catch(Exception &exception)
        {
          swprintf(ws1, L"ERROR: %ls (e020212)", exception.Message.c_str());
          DialogMessageBox(ws1);
          goto fail1;
        }
    
    


     

    Any ideas on why this exception would be thrown only at 2am when the software restarts itself and then not at other times of the day?

     

    The software is launched by another process and it is closing itself down fine according to the log:

     

    2023-06-08 02:01:46.942  Exiting
    2023-06-08 02:02:13.473  Starting
    2023-06-08 02:02:16.879  ERROR: Unsupported media file scaleitem.wmv (e020212)

     


  4. Thanks for the advice.  On Friday I discovered an unexpected thing with sprintf/swprintf that string conversion from narrow to wide and vice versa uses a buffer that is limited to 512 bytes.  I traced this down to the source code (in vprinter.c) to see that that is what it is doing.  I typically think of sprintf/swprintf as commands as being designed to emit data directly as to not be limited by a buffer size, but clearly that isn't the case.  Trying to convert a larger string will corrupt a program from a buffer overrun.  Why they didn't just code it to do a simple bufferless conversion in place does not make sense to me, especially since they aren't really properly converting between UTF-8 and UTF-16 anyway, but it is what it is.

     

    I found the WIN32 API functions MultiByteToWideChar and WideCharToMultiByte, but at the same time I've been thinking about how I can better handle string conversion and variable width strings in general to support UTF-8/UTF-16 better.

     


  5. So as a test I tried to set a TEdit to a UTF-8 sequence and it ended up as a series of characters and not the smile face I was testing.

     

    If I convert it first to a wide string and then assign the wide string it works:

    MultiByteToWideChar(CP_UTF8, 0, "\xf0\x9f\x98\x82", -1, ws1, 1024);

     

    Is there a way to make it recognizing a narrow string assignment as UTF-8 - some sort of code page setting in the application maybe?  or will it not do that?


  6. I've been using:

     

    unsigned char data[]={
    255,216,255,225,7,132,69,120,105,102,0,0,77,77,0,42,0,0,0,8,0,12,1,0,0,3,0,0,0,1,1,144,0,0,1,1,0,3,0,0,0,1,1,11,0,0,1,2,0,3,0,0,0,3,0,0,0,158,1,6,0,3,0,0,0,1,0,2,0,0,1,18,0,3,0,0,0,1,0,1,0,0,1,21,0,3,0,0,0,1,0,3,0,0,1,26,0,5,0,0,0,1,0,0,0,164,1,27,
    0,5,0,0,0,1,0,0,0,172,1,40,0,3,0,0,0,1,0,2,0,0,1,49,0,2,0,0,0,31,0,0,0,180,1,50,0,2,0,0,0,20,0,0,0,211,135,105,0,4,0,0,0,1,0,0,0,232,0,0,1,32,0,8,0,8,0,8,0,10,252,128,0,0,39,16,0,10,252,128,0,0,39,16,65,100,111,98,101,32,80,104,111,116,111,115,104,

    ...

    };

     

    But it is a large amount of data and I wonder if there is a better way?

     


  7. I am trying to get the programdata folder.  I've been using:

     

    cppbuilder 10.3.3

    LPITEMIDLIST pidl

    SHGetSpecialFolderLocation(NULL, CSIDL_COMMON_APPDATA, &pidl)

    SHGetPathFromIDListW(pidl, APath)

     

    This works fine in a VCL application, but a FireMonkey application, none of it is recognized.

     

    I tried to include <shlobj_core.h>, but this gives 1500+ warnings about the below and then fails.

     

    [bcc32 Warning] shobjidl_core.h(26477): W8026 Functions with exception specifications are not expanded inline
      Full parser context
        mycode.cpp(33): #include c:\program files (x86)\embarcadero\studio\20.0\include\windows\sdk\shlobj_core.h
        shlobj_core.h(86): #include c:\program files (x86)\embarcadero\studio\20.0\include\windows\sdk\shobjidl_core.h
        shobjidl_core.h(26477): decision to instantiate: ACTIVATEOPTIONS |(ACTIVATEOPTIONS,ACTIVATEOPTIONS) throw()
        --- Resetting parser context for instantiation...

     

    I was using this function because this code has to run on some older compilers, but if I can't get it to work I can use something else.

     


  8. 6 hours ago, Roger Cigol said:

    To make sure we understand what you are trying to do. You are trying to use the DEF file to specify to the linker which functions to export (and the names of the functions you want them exported as).   <can you confirm this, please?>

    Yes, that is exactly what I am trying to do.

     

    >Can you confirm that you are using the clang32 compiler for your 32bit code  (if not then first thing to try is to use the clang32 compiler - maybe it's name mangling will be the same as the clang64 (I haven't checked this)).

     

    I am using the classic compiler, I just have more experience with it so I stick with it.  I would think the clang compiler would still mangle/underscore the names for 32-bit code.

     


  9. 2 hours ago, David Heffernan said:

    Doesn't

    EXPORTS
      CCfgClassNew

    work?

    No, it comes up with an error:

    [ilink32 Warning] Warning: Attempt to export non-public symbol 'CCfgClassNew'

    The problem is that 32-bit mangles the name with an underscore and 64-bit does not, which is why I am using the DEF file to unmangle the 32-bit version of the DLL so it and the 64-bit version have consistent names.

     

    ALSO, one more odd thing.  if the DEF file changes in any way, this error is produced when trying to build:

    [ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.

     

    The way to fix it is to remove the DEF file and add the DEF file back again, then it will build without the error.

     


  10. Everyone, maybe I should have specified C++Builder.  The DEF files are for compiling two different versions, 32-bit and 64-bit DLL's.

     

    32-bit version top two lines:

     

    EXPORTS
      CCfgClassNew=_CCfgClassNew

     

    64-bit version top two lines:

    EXPORTS
      CCfgClassNew=CCfgClassNew

     

    The 64-bit lacks the underscore, my goal here being to produce a DLL that uses the same name for the function no matter whether it is 32-bit or 64-bit.  I want to access it as CCfgClassNew either way.

     

    Maybe there is no way to do this in a DEF file and I have to do different projects.


  11. I still have some projects in the old bcb6 that I need to compile sometimes.  One thing I noticed is that if I create a new win32 console mode application, it doesn't let me replace main;

     

    int main(int argc, char* argv[])

     

    With wmain:

     

    int wmain(int argc, wchar_t* argv[])

     

    In cppb10 there is an option _TCHAR maps to where you can select char or wchar_t and this seems to clue the linker in to look for main or wmain.  Is there an equivalent option for bcb6? (for anyone who remembers this old compiler!)

     

    I tried looking in the compiler/linker settings, but I am missing it or it doesn't exist.

     

×